Performance Odoo: indici, query, infrastruttura per PMI italiane (guida tuning)

Quarantunesima guida operativa Odoo 19 per PMI italiane. Un sistema Odoo che si carica in 1 secondo a inizio progetto può diventare un sistema da 12 secondi dopo 3 anni di volumi crescenti. La differenza tra una PMI che mantiene performance eccellenti e una che lavora con utenti frustrati è la cura proattiva: monitoring, indici database, query optimization, infrastructure tuning. In questa guida vediamo come ottimizzare le performance Odoo per volumi alti, con interventi a livello applicativo, database e infrastruttura.

Vediamo: KPI di performance, livelli di ottimizzazione, indici PostgreSQL, query optimization, caching, infrastruttura, monitoring tool, casi pratici PMI italiane.

KPI di performance da monitorare

Frontend (UX utenti)

• Time to First Byte (TTFB): < 500ms target
• Page Load Time: < 2 secondi per liste tipiche
• List view load: < 1 secondo per 80 record
• Form save: < 500ms per record standard
• Search response: < 300ms per ricerche con indici

Backend (server)

• CPU avg: < 60% sostenuto, picchi < 85%
• RAM usage: < 75% del totale
• Postgres connections: < 70% del max_connections
• Disk I/O: monitorare wait time, target < 5ms
• Long queries: < 5/giorno sopra 5 secondi

User experience (qualitativi)

• Numero ticket “sistema lento” per settimana
• NPS utenti su responsiveness
• Abbandono task per slowness

Livelli di ottimizzazione

1. Application layer (Odoo)

• Indici sui campi searched/filtered
• Eliminazione customization che fanno query in loop
• Caching computed fields con store=True
• Ottimizzazione record rules complesse
• Disabilitazione moduli inutilizzati

2. Database layer (PostgreSQL)

• Configurazione PostgreSQL tunata
• VACUUM e ANALYZE periodici
• Indici personalizzati per query frequenti
• Partitioning per tabelle storiche (oltre 10M record)
• Read replica per reporting

3. Infrastructure layer

• Server dimensionato correttamente (CPU, RAM, disk)
• NVMe SSD obbligatori per database
• Worker Odoo configurati per CPU disponibili
• Reverse proxy con caching (Nginx)
• CDN per asset statici (Cloudflare)

Indici database: il primo intervento

Cosa è un indice e perché importa

• Database scansiona riga per riga senza indici (slow)
• Con indici: lookup in tempo logaritmico (fast)
• Trade-off: write più lente (mantenimento indice)

Indici obbligatori per Odoo

• Tutti i campi many2one (relazioni) hanno indice di default
• Campi usati come filtri frequenti: aggiungere indice esplicito
• Campi con tracking=True: indice utile per audit log query
• Campi date/datetime in report frequenti

Verifica indici esistenti

Una vista dei modelli Odoo permette di identificare quali tabelle ospitano i dati critici. Da qui parte ogni analisi di performance database:

• Identificare tabelle con > 100k record
• Verificare query lente che le toccano
• Aggiungere indici mirati
• Misurare miglioramento (EXPLAIN ANALYZE)

Esempio: aggiungere indice custom

# In modello Python custom
priority = fields.Selection([...], index=True)

# O via SQL diretto (sconsigliato in produzione)
CREATE INDEX idx_lead_priority ON crm_lead(priority);

Saved filters: ottimizzare ricerche ricorrenti

I filtri salvati Odoo permettono agli utenti di accedere rapidamente a viste pre-configurate. Da un punto di vista performance, sono anche un modo per evitare ricerche ad-hoc costose:

• Filtro “ordini mese corrente” usato 100 volte/giorno
• Salvarlo = stessa query SQL ottimizzata
• Cache PostgreSQL ricorda risultato
• Indici dedicati per filtri frequenti

Server Actions: pulizia per performance

Le server actions e gli automated actions sono potenti ma possono diventare collo di bottiglia se accumulate senza criterio. Audit periodico è essenziale:

• Audit annuale automated actions: quali sono ancora rilevanti
• Time-based actions: convertire in cron schedulato se frequenza bassa
• Actions in cascata: identificare se ne servono tutte
• Action complesse: refactor in moduli Python custom

Configurazione PostgreSQL per Odoo

Parametri chiave (PMI 30-80 utenti)

Parametro	Valore raccomandato	Note
shared_buffers	25% RAM	Cache PostgreSQL
effective_cache_size	50-75% RAM	Cache OS hint
work_mem	16-64MB	Memoria per query
maintenance_work_mem	256MB-1GB	VACUUM, CREATE INDEX
max_connections	100-200	Dipende worker Odoo
wal_buffers	16MB	Write-ahead log
checkpoint_completion_target	0.9	Spread I/O
random_page_cost	1.1	Per SSD

Maintenance routine

• VACUUM ANALYZE settimanale (autovacuum se ben configurato)
• REINDEX trimestrale su tabelle critiche
• Monitoring bloat (vedi pg_stat_user_tables)
• Update statistics (ANALYZE) post-import massivi

Worker Odoo: scaling orizzontale

Configurazione worker

• workers = (2 × CPU) + 1 per HTTP request
• cron_workers = 1-2 per scheduled actions
• longpolling_port separato per chat/notifiche real-time
• Memory limit per worker: 2-4GB (RAM/workers)

Esempio configurazione PMI 50 utenti

# odoo.conf
workers = 9       # Server 4 CPU
max_cron_threads = 2
limit_memory_soft = 2147483648  # 2GB
limit_memory_hard = 2684354560  # 2.5GB
limit_request = 8192
limit_time_cpu = 600
limit_time_real = 1200

Load balancing multi-server

• Per > 100 utenti: setup multi-server con load balancer
• Nginx + 2-4 Odoo server
• Database centrale + read replica per reporting
• Session storage Redis condiviso

Caching strategies

Browser cache (asset statici)

• Cache-Control headers per JS, CSS, immagini
• Versioning asset via Odoo automatico
• CDN (Cloudflare) per cache distribuita geograficamente

Application cache

• Computed fields store=True evitano ricalcolo
• Cache ormcache per metodi pesanti
• Invalidazione automatica su modifiche

Database cache

• PostgreSQL shared_buffers ben dimensionato
• Query plan cache
• Connection pooling (PgBouncer per > 100 utenti)

Identificare bottleneck

Tool di monitoring

• Odoo profile dev mode: timing per ogni richiesta
• PostgreSQL pg_stat_statements: query più frequenti/lente
• Application Performance Monitoring (APM): NewRelic, DataDog, Sentry
• Server monitoring: Prometheus + Grafana
• Log aggregation: ELK stack o Loki

Workflow troubleshooting

• Identifica metrica peggiorata (es. “lista clienti caricamento lento”)
• Riproduci problema in staging
• Profile dev mode per identificare metodi lenti
• Analizza query SQL via pg_stat_statements
• Implementa fix mirato
• Misura miglioramento before/after
• Deploy produzione + monitoring

Ottimizzazioni Odoo-specifiche

Disabilitare moduli inutilizzati

• Ogni modulo aggiunge: codice, tabelle, indici, computed fields
• Audit annuale “moduli installati vs effettivamente usati”
• Disinstallazione moduli non usati > 6 mesi
• Beneficio tipico: -10/30% memoria, -5/15% startup time

Ottimizzare record rules

• Record rules complesse rallentano OGNI query sul modello
• Refactor domain con campi indicizzati
• Evitare nested queries in record rules
• Caching tramite computed fields helper

Archive dati storici

• Record > 5 anni: candidate per archiviazione
• Mantieni accessibili via “Show Archived” filter
• Riduce dimensione tabelle live
• Per dati molto vecchi: dump in tabella separata o file

Errori comuni nel performance tuning

“Aggiungere indici senza misurare”

Problema: 50 indici creati, performance peggiorate (write lente).
Soluzione: misurare prima e dopo ogni indice. EXPLAIN ANALYZE in mano.

“Ottimizzare prematuramente”

Problema: 2 settimane di tuning per query usata 3 volte al giorno.
Soluzione: profile prima, ottimizza solo quello che impatta UX reale.

“Upgrade hardware senza tuning software”

Problema: triplicare RAM/CPU senza ottimizzare configurazione.
Soluzione: hardware è ultima leva. Prima tuning PostgreSQL + Odoo worker.

“Monitoring assente fino a problema critico”

Problema: si scopre lentezza da utenti, già troppo tardi.
Soluzione: monitoring proattivo + alert automatici (es. response time > 2s).

“Single-server fino a 200 utenti”

Problema: insistere con 1 server con CPU al 95%.
Soluzione: scaling orizzontale a partire da 80-100 utenti concorrenti.

Costi tipici performance tuning

Intervento	Effort	Costo tipico
Audit performance + report	2-4 giorni	1.500-3.500 €
Tuning PostgreSQL + Odoo config	2-3 giorni	1.500-2.500 €
Aggiunta indici mirati (10-30 indici)	1-2 giorni	800-1.800 €
Refactor record rules complesse	3-7 giorni	2.500-6.000 €
Setup monitoring + alerting	3-5 giorni	2.500-4.500 €
Multi-server architecture	10-20 giorni	10.000-25.000 €

Casi pratici PMI italiane

Caso 1 — Manifattura: tuning PostgreSQL

• Sistema lento dopo 2 anni (DB 80GB)
• Tuning shared_buffers + work_mem + autovacuum
• Aggiunta 15 indici mirati
• Effort: 5 giorni, costo 4k €
• Risultato: lista ordini -70% tempo carico (da 8s a 2.4s)

Caso 2 — Distributore: multi-server architecture

• 120 utenti concorrenti, server saturato
• Setup: load balancer + 3 Odoo nodes + DB replicato
• Effort: 18 giorni, costo 18k €
• Risultato: capacità 300 utenti, response time stabile

Caso 3 — Servizi B2B: archive dati storici

• 10 anni di timesheet (4M record), query lente
• Archiviazione record > 5 anni in tabella separata
• Query report -85% tempo (da 45s a 6s)
• Effort: 4 giorni, costo 3.2k €

Caso 4 — E-commerce: indici per ricerca prodotti

• 500k prodotti, ricerca lenta (5-8s)
• Indice GIN su trigrammi per fuzzy search
• Effort: 3 giorni, costo 2.5k €
• Risultato: ricerca < 300ms, conversion +18%

FAQ

Quanto dura il tuning prima di vedere benefici?

Quick wins: 1-3 giorni (tuning config, indici basici) → miglioramento 30-50% percepito. Ottimizzazioni avanzate: 2-4 settimane → miglioramento sostenuto. Multi-server: 2-3 mesi setup + 1 mese stabilization.

Quando passare da single-server a multi-server?

Soglia tipica: 80-100 utenti concorrenti su 4 CPU. Sopra: scaling verticale (più CPU/RAM) fino a 8-16 CPU. Oltre: scaling orizzontale (load balancer + multi-node) obbligatorio. Eccezione: workload mixed (CPU-bound + I/O bound) può richiedere multi-server prima.

Quanto costa un server adeguato per PMI 50 utenti?

Cloud (AWS/Azure/GCP): 4-8 vCPU, 16-32GB RAM, 200-500GB NVMe SSD = 300-700 €/mese. Hosting dedicato (OVH, Hetzner): 50-200 €/mese per server equivalente ma meno managed. Per produzione: backup + monitoring +50% del costo base.

Posso usare Odoo Online (SaaS) per PMI grande?

Odoo Online è ottimo per PMI fino a 30-50 utenti con scope standard. Sopra questa soglia o con personalizzazioni: meglio Odoo.sh (managed self-hosted) o on-premise. Limitazioni Odoo Online: customization Python custom, performance tuning, backup self-managed.

Quanto spesso dovrei fare performance audit?

Audit completo annuale + quick check trimestrale. Audit straordinario quando: volumi crescono > 30%, lamentele utenti aumentano, dopo upgrade major, dopo aggiunta moduli importanti. Monitoring continuo evita audit emergency.

Prossimi passi

Nelle prossime guide vedremo come gestire backup e disaster recovery in ottica business continuity, come scalare il sistema a 200+ utenti, e come migrare a infrastruttura cloud mantenendo performance.

Vuoi ottimizzare le performance Odoo della tua PMI?
G Tech Group offre performance audit Odoo per PMI italiane: tuning PostgreSQL, indici, configurazione worker, monitoring proattivo, scaling architecture. Riduzione tempo di risposta tipica del 50-70%.
Richiedi un preventivo gratuito oppure prova la nostra demo Odoo 19 live. Oppure prova Odoo direttamente su odoo.com (link partner Brentasoft).