Apri l'elenco delle fatture e devi aspettare dieci secondi. Generi un report e il browser mostra una schermata bianca prima di caricare i dati. Avvii una ricerca prodotto e tutto si blocca mentre il database elabora le query. Se queste situazioni ti suonano familiari, la tua istanza Dolibarr soffre di un problema di prestazioni. E in oltre l'ottanta per cento dei casi, il colpevole non è né PHP né il browser, ma il database MySQL o MariaDB che si trova dietro al tuo ERP/CRM.
Un database mal configurato trasforma un Dolibarr reattivo in uno strumento che i tuoi team finiscono per aggirare. Tornano a Excel, a note manoscritte o a strumenti terzi, e la promessa di un sistema informativo unificato crolla. La buona notizia è che la stragrande maggioranza dei problemi di lentezza deriva da cause note, identificabili e risolvibili. In questa guida, NEXT GESTION condivide cinque trucchi tecnici comprovati su centinaia di istanze Dolibarr in produzione, da rivenditori con dieci utenti fino a industrie con diverse centinaia di connessioni simultanee. Questi trucchi coprono la configurazione del motore, gli indici, la manutenzione, la cache e l'architettura del server. Applicati correttamente, possono dividere per tre, cinque o anche dieci i tempi di risposta della tua applicazione.
Indice
- Perché Dolibarr rallenta nel tempo: capire le cause
- Diagnosi preliminare: misurare prima di ottimizzare
- Trucco n°1: ottimizzare la configurazione MySQL/MariaDB
- Trucco n°2: lavorare sugli indici e sulla struttura delle tabelle
- Trucco n°3: manutenzione regolare del database
- Trucco n°4: attivare e configurare le cache applicative
- Trucco n°5: adattare l'architettura server al carico
- Ottimizzazioni specifiche lato Dolibarr
- Sorveglianza e monitoraggio continuo
- Errori classici da evitare
- Casi di studio concreti
- Quando rivolgersi a un esperto?
- FAQ: domande frequenti sulle prestazioni Dolibarr
1. Perché Dolibarr rallenta nel tempo: capire le cause
Quando inizi con Dolibarr, l'applicazione è veloce. Tutto va liscio, le pagine si visualizzano istantaneamente e l'esperienza utente è piacevole. Sei mesi, un anno o due dopo, la stessa applicazione impiega cinque, dieci o venti secondi per visualizzare lo stesso elenco. Cosa è successo?
Si combinano diversi fenomeni. Innanzitutto, il volume dei dati cresce: fatture, proposte commerciali, ordini, movimenti di magazzino, scritture contabili, email archiviate, allegati. Una tabella che conteneva diecimila righe ora ne ha cinquecentomila, e alcune query mal scritte passano da un millisecondo a due secondi. Poi, il numero di utenti simultanei cresce con l'azienda, moltiplicando le connessioni concorrenti e i blocchi sulle tabelle. I moduli aggiuntivi installati nel tempo aggiungono le proprie query e tabelle. Gli indici inizialmente presenti non bastano più per i nuovi usi. La cache applicativa non è abilitata o è mal dimensionata. Infine, la configurazione MySQL fornita di default dal tuo hosting, progettata per un server da un gigabyte di memoria, non è mai stata adeguata alla realtà della tua infrastruttura.
Capire questi meccanismi è essenziale prima di agire. Le prestazioni non sono uno stato statico ma un equilibrio dinamico tra volume di dati, carico utente, qualità del codice, indici disponibili e risorse hardware allocate. Un'ottimizzazione efficace agisce simultaneamente su più di questi assi, ed è esattamente ciò che dettaglieremo nei cinque trucchi seguenti.
2. Diagnosi preliminare: misurare prima di ottimizzare
La regola d'oro di ogni ottimizzazione è semplice: non si ottimizza ciò che non si misura. Prima di modificare anche solo una riga di configurazione, prenditi il tempo per stabilire una diagnosi quantificata e riproducibile della tua situazione attuale. Senza un punto di riferimento, non potrai sapere se le tue modifiche hanno portato un guadagno reale o se hai semplicemente spostato il problema.
Inizia identificando le pagine più lente dal punto di vista dell'utente. Gli strumenti per sviluppatori del tuo browser, accessibili con il tasto F12, mostrano il tempo di caricamento completo di ogni pagina, il tempo trascorso sul server e il tempo di rendering lato client. Annota queste misurazioni per cinque-dieci azioni critiche del tuo quotidiano: apertura dell'elenco fatture, ricerca cliente, generazione di un report, validazione di un ordine, accesso alla scheda di un prodotto con le sue scorte. Questi numeri costituiscono il tuo punto di riferimento.
Attiva poi il log delle query lente lato MySQL o MariaDB, fissando una soglia bassa, ad esempio un secondo. Questo log cattura tutte le query che superano questa soglia e rivela immediatamente i colli di bottiglia. Combinato con uno strumento di analisi come pt-query-digest o mysqldumpslow, classifica le query per tempo cumulativo, frequenza e tempo medio, indicandoti esattamente dove concentrare i tuoi sforzi. Esamina anche le statistiche globali del server: rapporto di hit della cache InnoDB, rapporto di connessioni abbandonate, query in attesa di lock, tabelle temporanee scritte su disco. Questi indicatori orientano immediatamente la diagnosi.
Lato Dolibarr, attiva la modalità debug nella configurazione e consulta il log applicativo per individuare moduli o hook che aggiungono tempo a ogni pagina. Misura la dimensione del tuo database, la dimensione di ogni tabella principale e il numero di righe contenute. Una tabella di log che pesa diversi gigabyte o una tabella eventi con diversi milioni di righe è un campanello d'allarme immediato. Una volta tracciato questo panorama, sai dove ti trovi e puoi affrontare le ottimizzazioni con piena cognizione di causa.
3. Trucco n°1: ottimizzare la configurazione MySQL/MariaDB
La configurazione di default di MySQL o MariaDB è una delle leve più rapide e remunerative per guadagnare in prestazioni. È volutamente conservativa, prevista per funzionare su un server modesto senza rischio di saturazione di memoria. Su un server dedicato a Dolibarr con otto, sedici o trentadue gigabyte di RAM, questa configurazione lascia letteralmente il novanta per cento delle risorse inutilizzate.
Il parametro più impattante è senza dubbio la dimensione del buffer InnoDB. InnoDB è il motore di archiviazione utilizzato da tutte le tabelle Dolibarr moderne, e il suo buffer è la zona di memoria in cui MySQL mette in cache le pagine di dati e indici. Più questo buffer è grande, meno il server ha bisogno di leggere dal disco, e più le query sono veloci. La regola generalmente accettata consiste nell'allocare tra il settanta e l'ottanta per cento della RAM totale del server a questo buffer se la macchina è dedicata al database. Su un server condiviso che ospita anche PHP e il server web, si scenderà al cinquanta o sessanta per cento, vegliando a lasciare memoria sufficiente al resto del sistema.
Altri parametri meritano un aggiustamento attento. La dimensione del log InnoDB influisce direttamente sulle prestazioni in scrittura: un log troppo piccolo provoca flush troppo frequenti e rallenta gli inserimenti massivi. Il numero massimo di connessioni deve riflettere la realtà del tuo carico senza essere smisurato, perché ogni connessione consuma memoria. Il buffer di ordinamento, il buffer di join e la cache delle tabelle temporanee devono essere adattati alle tue query più complesse, senza essere sovradimensionati al punto da saturare la RAM in punta di carico. La modalità di flush delle transazioni InnoDB può essere regolata in base alla tua tolleranza al rischio: il valore più sicuro garantisce la durabilità di ogni transazione al costo di più scritture su disco, mentre un valore intermedio offre un eccellente compromesso per la maggior parte delle PMI.
Infine, non dimenticare il motore della query cache, ora disabilitato di default sulle versioni recenti di MariaDB e completamente rimosso su MySQL. Se sei ancora su una versione vecchia con questa cache attivata e il tuo carico è prevalentemente in scrittura, può paradossalmente rallentare l'applicazione. Un audit di configurazione consente di determinare con precisione cosa attivare, regolare o disattivare. NEXT GESTION pratica sistematicamente questo esercizio durante i suoi interventi e fornisce file di configurazione adattati a ogni dimensione di istanza.
4. Trucco n°2: lavorare sugli indici e sulla struttura delle tabelle
Se la configurazione del motore è la leva più rapida, gli indici sono la più potente. Un indice ben posizionato può trasformare una query da cinque secondi in una query da un millesimo di secondo. Al contrario, un indice mancante su una colonna frequentemente filtrata costringe il database a percorrere l'intera tabella, operazione il cui costo esplode man mano che i dati crescono.
Dolibarr è fornito con un set ragionevole di indici che coprono gli usi standard. Tuttavia, non appena aggiungi moduli di terze parti, campi personalizzati o estensioni sviluppate su misura, questi indici possono diventare insufficienti. Una ricerca per riferimento interno sulla tabella prodotti, un filtro per stato sulla tabella fatture combinato con un ordinamento per data, un join tra due tabelle figlie di un modulo aggiuntivo: tanti scenari in cui un indice complementare fa la differenza tra un'esperienza fluida e un'esperienza laboriosa.
L'identificazione degli indici mancanti avviene a partire dal log delle query lente e dallo strumento EXPLAIN integrato in MySQL. EXPLAIN dettaglia la strategia di esecuzione scelta dal motore per ogni query: utilizzo di un indice, lettura sequenziale completa, join annidato, tabella temporanea in memoria o su disco. Una query che mostra la parola ALL nella colonna type o diversi milioni di righe scansionate è un candidato evidente all'ottimizzazione. La creazione di un indice mirato, talvolta composito su più colonne nel giusto ordine, è quindi sufficiente per correggere il problema.
Attenzione tuttavia a non cadere nell'eccesso. Ogni indice ha un costo in scrittura: ad ogni inserimento, aggiornamento o cancellazione, MySQL deve aggiornare gli indici interessati. Aggiungere dieci indici a una tabella molto sollecitata in scrittura può degradare le prestazioni globali. La buona pratica consiste nell'indicizzare ciò che è realmente usato, eliminare gli indici ridondanti o inutilizzati, e privilegiare indici compositi ben pensati piuttosto che una moltiplicazione di indici semplici. Lato struttura, verifica anche che le tue colonne usino i tipi giusti: un VARCHAR generosamente dimensionato consuma più memoria di ordinamento di un VARCHAR adeguato, un TEXT dove basterebbe un VARCHAR impedisce certe ottimizzazioni, un tipo DATE è sempre più veloce di una data memorizzata come stringa. Un audit dello schema da parte di un esperto Dolibarr identifica questi punti di miglioramento spesso invisibili dall'interfaccia.
5. Trucco n°3: manutenzione regolare del database
Un database è un organismo vivente. Inserimenti, aggiornamenti e cancellazioni successive frammentano le pagine, fanno gonfiare gli indici oltre la loro dimensione ottimale, desincronizzano le statistiche utilizzate dall'ottimizzatore di query e accumulano dati obsoleti che nessuno consulta più. Senza manutenzione regolare, questi fenomeni finiscono per degradare sensibilmente le prestazioni, anche senza alcuna nuova attività di business.
La prima operazione di manutenzione è la deframmentazione delle tabelle. Su InnoDB, questa operazione viene eseguita da un comando che ricostruisce la tabella e i suoi indici recuperando lo spazio libero, riorganizzando le pagine e riadattando la dimensione del file dati. Eseguita trimestralmente sulle tabelle principali, limita l'espansione artificiale del database e preserva la località dei dati, cioè la prossimità fisica delle righe spesso lette insieme. Le tabelle molto sollecitate in scrittura, come la tabella delle scritture contabili, la tabella dei journal o la tabella delle scorte, beneficiano particolarmente di questa deframmentazione.
La seconda operazione è l'aggiornamento delle statistiche. L'ottimizzatore MySQL sceglie il suo piano di esecuzione basandosi su statistiche che stimano la cardinalità degli indici e la distribuzione dei valori. Se queste statistiche sono obsolete, l'ottimizzatore può prendere decisioni assurde, ad esempio rifiutarsi di usare un indice perfettamente adatto perché pensa che la tabella contenga ancora mille righe quando ne ha ora un milione. Il comando di aggiornamento delle statistiche, eseguito periodicamente, garantisce che i piani di esecuzione restino pertinenti.
La terza operazione è l'archiviazione e l'eliminazione dei dati obsoleti. Log applicativi, sessioni scadute, allegati di email di cinque anni fa, documenti intermedi non validati, report generati al volo: tanti dati che occupano spazio senza valore di business reale. Una politica di retention chiara, documentata e automatizzata permette di mantenere il volume sotto controllo. Su alcune basi che NEXT GESTION ha auditato, oltre il sessanta per cento del volume era dedicato a dati che nessun utente consultava da anni. Una semplice eliminazione con archiviazione offline ha permesso di dividere per tre la dimensione del database e accelerare meccanicamente tutte le operazioni.
Infine, non dimenticare la verifica di integrità. Una corruzione silenziosa, anche minore, su una tabella critica può generare comportamenti aberranti difficili da diagnosticare. Una verifica mensile delle tabelle principali e un monitoraggio dei log degli errori MySQL prevengono gli incidenti prima che diventino visibili lato utente.
6. Trucco n°4: attivare e configurare le cache applicative
La migliore query è quella che non si esegue. Questa massima riassume perfettamente la logica della cache: conservare in memoria il risultato di operazioni costose per servirle istantaneamente alle query successive. Dolibarr e il suo ecosistema PHP offrono diversi livelli di cache che, configurati correttamente, possono ridurre drasticamente il carico sul database.
La prima cache da attivare è l'opcache di PHP. Senza opcache, PHP rilegge, analizza e compila ogni file sorgente ad ogni richiesta, consumando CPU e tempo in modo significativo. Con opcache attivato, il bytecode compilato è conservato in memoria e riutilizzato, il che può dimezzare il tempo di risposta globale dell'applicazione. La configurazione consiste nell'allocare memoria sufficiente per memorizzare tutti i file di Dolibarr, autorizzare un numero di file coerente con la dimensione della tua installazione e regolare i parametri di validazione per evitare verifiche inutili in produzione. È un'ottimizzazione semplice, gratuita e dal guadagno quasi sempre spettacolare.
Il secondo livello riguarda la cache applicativa di Dolibarr stesso. Diverse zone dell'applicazione possono essere messe in cache: liste di paesi, valute, tipi di pagamento, diritti utente, parametri di configurazione globali, traduzioni. Questi dati sono letti a quasi ogni pagina ma cambiano molto raramente. Conservarli in memoria evita decine, persino centinaia di query ridondanti ad ogni caricamento. A seconda dei moduli installati e della versione utilizzata, queste cache possono essere attivate tramite parametri avanzati o estensioni dedicate.
Per istanze a maggiore carico, è pertinente andare oltre con una cache esterna condivisa tra i processi PHP. Soluzioni come Redis o Memcached permettono di mettere in cache risultati di query complesse, sessioni utente o oggetti business ricostituiti. Il guadagno è particolarmente netto su dashboard, aggregazioni di numeri e pagine caricate contemporaneamente da molti utenti. La messa in opera richiede una configurazione accurata, una strategia di invalidazione rigorosa e un monitoraggio attivo per garantire la coerenza dei dati visualizzati. È tipicamente un intervento che NEXT GESTION accompagna end-to-end sulle istanze Dolibarr più esigenti.
Non dimentichiamo la cache del browser e la cache HTTP. Le risorse statiche di Dolibarr, come fogli di stile, script JavaScript e immagini, devono essere servite con header di cache appropriati per evitare che vengano riscaricate ad ogni pagina. Una configurazione accurata del web server, eventualmente integrata da un CDN per i deployment multi-sito, alleggerisce il carico di rete e migliora la percezione di rapidità lato utente.
7. Trucco n°5: adattare l'architettura server al carico
Tutte le ottimizzazioni software del mondo non possono compensare un server sottodimensionato o un'architettura inadeguata. Da un certo volume di dati, utenti simultanei o integrazioni connesse, diventa necessario rivedere le fondamenta hardware su cui poggia il tuo Dolibarr.
Il primo parametro da esaminare è la memoria RAM disponibile. Un database performante ha bisogno di RAM in abbondanza, principalmente per il buffer InnoDB evocato sopra. La regola empirica consiste nel mirare a una RAM totale almeno pari alla dimensione della parte attiva del tuo database, cioè le tabelle e gli indici che consulti regolarmente. Un server da otto gigabyte per una base attiva di quindici gigabyte passerà metà del suo tempo a leggere dal disco, qualunque sia il tuo tuning. Aumentare la RAM è spesso l'investimento hardware più redditizio.
Il secondo parametro è il sottosistema di archiviazione. Il passaggio da un disco meccanico a un SSD divide generalmente per dieci le latenze di lettura casuale, il che trasforma l'esperienza utente sulle query complesse. Il passaggio da un SSD SATA a un SSD NVMe apporta un guadagno aggiuntivo significativo sui carichi intensivi in scrittura. Sugli hosting virtualizzati, verifica la classe di archiviazione proposta e non esitare a salire di gamma se le tue misurazioni indicano un collo di bottiglia disco.
Il terzo parametro riguarda la CPU. Dolibarr e il suo motore PHP sono sensibili alla frequenza di clock, ancora più che al numero di core, per le query individuali. Per contro, sui carichi multi-utente, il numero di core diventa determinante per assorbire le query in parallelo. Un audit del carico medio, dei picchi e della natura delle operazioni permette di scegliere la giusta combinazione.
Oltre al dimensionamento verticale di una singola macchina, esistono architetture più avanzate per le istanze molto sollecitate. La separazione del web server e del database server su due macchine distinte distribuisce il carico ed evita conflitti di risorse. La messa in opera di una replica primario-secondario permette di scaricare le query di lettura pesanti su una replica conservando le scritture sul server principale. L'uso di un proxy di connessione per condividere le connessioni PHP lato MySQL riduce il carico in punta. Queste architetture si giustificano oltre una certa soglia di criticità o volume e si inscrivono in una riflessione globale sull'alta disponibilità che NEXT GESTION conduce con i suoi clienti medio-grandi.
Infine, la rete gioca un ruolo spesso sottovalutato. Una latenza eccessiva tra il browser dell'utente, il web server e il database server degrada considerevolmente l'esperienza, soprattutto sulle pagine che moltiplicano gli scambi. Un hosting situato in prossimità geografica dei tuoi utenti principali e una rete interna a bassa latenza tra le diverse componenti dell'architettura fanno spesso la differenza sui workflow di business intensivi.
8. Ottimizzazioni specifiche lato Dolibarr
Oltre al motore di database e all'architettura, Dolibarr stesso offre diverse leve di ottimizzazione. La disattivazione dei moduli inutilizzati è probabilmente la più semplice ed efficace. Ogni modulo attivato carica le proprie librerie, esegue i propri hook ad ogni pagina e consuma risorse anche se non lo usi. Selezionare i moduli realmente necessari riduce il numero di query per pagina e accelera il caricamento globale.
La gestione dei campi personalizzati merita anche un'attenzione particolare. Un campo personalizzato mal progettato, ad esempio una lista a discesa alimentata da una query pesante senza cache, può rallentare significativamente ogni apertura di scheda. Privilegia campi mirati, liste statiche quando possibile e query ottimizzate con indici appropriati.
Le esportazioni massive e i report pesanti devono essere pensati in termini di impatto sul sistema. Un'esportazione di centomila righe lanciata in pieno giorno da un utente può paralizzare l'applicazione per tutti gli altri. La messa in opera di code, pianificazione notturna o generazione in background permette di isolare queste operazioni senza impattare l'esperienza interattiva.
Lato interfaccia, alcune liste mostrano di default informazioni aggregate costose da calcolare, come il totale delle fatture in corso o lo stock valorizzato di un prodotto. Quando queste informazioni non sono critiche per l'uso quotidiano, la loro disattivazione o il calcolo a richiesta alleggerisce il rendering di ogni riga e accelera la navigazione. NEXT GESTION accompagna i suoi clienti nella personalizzazione fine di queste visualizzazioni per allineare le prestazioni alle vere esigenze di business.
9. Sorveglianza e monitoraggio continuo
Ottimizzare una volta non basta. Un'istanza Dolibarr evolve costantemente: nuovi utenti, nuovi moduli, nuovi dati, nuovi usi. Senza sorveglianza continua, i guadagni duramente acquisiti si degradano insidiosamente. Mettere in opera un monitoraggio permanente è quindi una tappa indispensabile di ogni approccio alle prestazioni durature.
Il monitoraggio copre diversi assi. A livello di sistema, si segue l'utilizzo della CPU, la memoria libera, la latenza e la velocità di archiviazione, il carico medio e il numero di processi attivi. A livello di database, si sorvegliano il rapporto di hit del buffer InnoDB, il numero di query lente al minuto, le connessioni attive, i lock in attesa e la dimensione delle tabelle principali. A livello applicativo, si strumentano le pagine più utilizzate per misurare il loro tempo di risposta e rilevare regressioni.
Queste metriche devono essere raccolte in uno strumento centralizzato che permetta di visualizzare le tendenze nel tempo, definire allarmi al superamento di soglia e correlare gli eventi. Strumenti open source come Prometheus con Grafana, o soluzioni all-in-one come Zabbix o offerte SaaS dedicate, permettono di mettere in opera questo dispositivo senza investimenti smisurati. Una dashboard chiara, consultata settimanalmente, dà una visione d'insieme della salute della piattaforma e orienta le azioni correttive.
Il follow-up degli incidenti completa la fotografia. Ogni rallentamento segnalato da un utente deve essere registrato, datato, messo in relazione con le metriche di sistema del momento e analizzato. Con il tempo, emergono pattern: il lunedì mattina satura sempre, la fine mese appesantisce la contabilità, certi utenti scatenano operazioni atipiche. Questa conoscenza fine del comportamento reale della tua istanza è preziosa per anticipare piuttosto che subire.
10. Errori classici da evitare
Nell'urgenza di un problema di prestazioni, certi tentativi ben intenzionati fanno più male che bene. Il primo errore consiste nel modificare più parametri contemporaneamente senza misurare l'impatto di ogni cambiamento. Se la situazione migliora, non saprai quale ha funzionato. Se peggiora, non potrai tornare indietro con precisione. Ogni modifica deve essere isolata, misurata e validata prima di passare alla successiva.
Il secondo errore è copia-incollare una configurazione MySQL trovata su un blog senza capirla. Una configurazione ottimizzata per un web server ad alto traffico non ha nulla a che vedere con una configurazione adatta a un ERP transazionale. Un file di parametri mal compreso può moltiplicare i bug, saturare la RAM o anche impedire l'avvio del servizio.
Il terzo errore è sovraindicizzare. Davanti a query lente, la tentazione è aggiungere un indice su ogni colonna menzionata in un WHERE. È raramente la risposta giusta. Un indice ben pensato vale più di dieci indici ridondanti, e ogni indice aggiunto penalizza le scritture.
Il quarto errore è ignorare i backup prima dell'intervento. Un'ottimizzazione, soprattutto sugli indici o sulla struttura delle tabelle, deve essere preceduta da un backup completo, verificato e ripristinabile. Lavorare senza rete su un database di produzione è un rischio che nessuno dovrebbe correre.
Infine, il quinto errore è sottovalutare l'effetto di apprendimento. Un'ottimizzazione produce il suo pieno effetto una volta che le cache sono calde, le statistiche sono aggiornate e gli utenti hanno ritrovato le loro abitudini. Misurare l'impatto nella prima ora può dare un'immagine ingannevole. Lascia girare per diversi giorni prima di trarre conclusioni definitive.
11. Casi di studio concreti
Per ancorare questi principi alla realtà, ecco tre esempi tratti dagli interventi di NEXT GESTION, anonimizzati ma fedeli alle situazioni incontrate.
Primo caso, un negoziante di materiale professionale che usa Dolibarr da cinque anni, con una base di dodici gigabyte e circa venticinque utenti simultanei. La diagnosi rivela un buffer InnoDB di centoventotto megabyte, il valore di default, su un server con sedici gigabyte di RAM. Primo intervento: regolazione della configurazione MySQL con il buffer portato a dieci gigabyte. Risultato immediato, tempi di risposta divisi per tre su tutte le schermate. Secondo intervento: analisi del log delle query lente e creazione di quattro indici complementari su campi personalizzati molto utilizzati. Risultato, i report passano da dodici secondi a meno di due. Terzo intervento: eliminazione di otto anni di log applicativi e allegati orfani. Risultato, base ridotta a cinque gigabyte e backup due volte più rapidi.
Secondo caso, una PMI industriale che gestisce il suo MRP con Dolibarr e diversi moduli aggiuntivi. I calcoli del fabbisogno richiedevano oltre quaranta minuti in pieno giorno e bloccavano l'applicazione. La diagnosi identifica una combinazione di query mal ottimizzate, assenza di indici adatti sulle tabelle di esplosione delle distinte base e opcache disattivato. Dopo riprogettazione delle query critiche, aggiunta di cinque indici mirati e attivazione di opcache, il calcolo globale scende a quattro minuti e può essere lanciato senza disturbare gli utenti.
Terzo caso, un grossista e-commerce con un Dolibarr connesso a un negozio online tramite un connettore che sincronizza permanentemente scorte e ordini. Sotto carico, l'applicazione diventava inutilizzabile. Diagnosi: architettura mono-server saturata, assenza di cache esterna, query ripetitive su dati poco variabili. Messa in opera di una separazione del web server e del database server, aggiunta di una cache Redis per le liste di referenziali e ottimizzazione delle query del connettore. Risultato, una piattaforma stabile anche in piena campagna commerciale, con tempi di risposta divisi per cinque.
12. Quando rivolgersi a un esperto?
Molte ottimizzazioni sono alla portata di un amministratore di sistema o di un integratore Dolibarr esperto. Le regolazioni di configurazione, l'attivazione di opcache, la messa in opera di un monitoraggio di base, la pulizia dei dati obsoleti possono essere condotti internamente con un po' di metodo e prudenza.
Tuttavia, alcune situazioni giustificano l'intervento di un esperto. Se le tue misurazioni non convergono verso una causa chiara, se le ottimizzazioni abituali non producono i guadagni attesi, se la tua istanza combina diversi moduli complessi o supera le volumetrie consuete, l'esperienza accumulata di uno specialista fa la differenza. Un audit approfondito identifica punti che un occhio non allenato può perdere: uno schema dati non ottimale, una query PHP che genera centinaia di sotto-query, un modulo terzo che consuma risorse sproporzionate, una configurazione di sistema incompatibile con il carico reale.
NEXT GESTION accompagna i suoi clienti in tutte le tappe di questo approccio. Audit di prestazioni documentato, piano di ottimizzazione quantificato, implementazione delle correzioni, formazione dei team interni al monitoraggio e al tuning continuo, contratti di manutenzione proattiva. Il nostro metodo si basa sulla misura, la trasparenza e la trasmissione di competenze affinché i tuoi team restino autonomi dopo il nostro intervento. Se il tuo Dolibarr rallenta e vuoi vederci chiaro, contattaci per una diagnosi preliminare.
13. FAQ: domande frequenti sulle prestazioni Dolibarr
Il mio Dolibarr è lento solo su certe pagine, devo comunque ottimizzare tutto il server? No. Una lentezza mirata punta quasi sempre verso un problema specifico: query mal scritta, indice mancante, modulo particolare, calcolo costoso. L'analisi del log delle query lente e l'uso di EXPLAIN spesso bastano per identificare la causa. Un'ottimizzazione globale del server verrà in un secondo tempo se la diagnosi lo giustifica.
Quanto dura un audit di prestazioni completo? Per un'istanza di PMI standard, un audit completo che include configurazione MySQL, indici, query, architettura e codice applicativo richiede tra i due e i cinque giorni a seconda della complessità. Le conclusioni sono restituite in un report dettagliato accompagnato da un piano d'azione prioritizzato.
Bisogna aggiornare Dolibarr per guadagnare in prestazioni? Spesso sì. Ogni versione maggiore apporta il suo lotto di ottimizzazioni sulle query più critiche, indici aggiuntivi e talvolta una riprogettazione di moduli completi. Migrare da una versione vecchia verso una versione recente apporta generalmente un guadagno misurabile, in complemento alle altre leve di ottimizzazione.
Un hosting condiviso può far girare Dolibarr correttamente? Per una struttura molto piccola con pochi utenti e pochi dati, sì. Oltre, i limiti degli hosting condivisi sulla memoria MySQL, i processi PHP e la latenza disco diventano proibitivi. Un VPS dedicato, anche modesto, offre un rapporto qualità-prezzo molto migliore non appena si supera il livello di qualche centinaio di fatture al mese.
Le prestazioni dipendono dal numero di utenti o dalla dimensione del database? Da entrambi, ma diversamente. La dimensione del database influisce sulla durata delle query individuali e sulla pressione sul buffer InnoDB. Il numero di utenti simultanei influisce sulla concorrenza sui lock, il consumo CPU e la memoria dei processi PHP. Un'ottimizzazione efficace tiene conto di queste due dimensioni.
Bisogna eliminare regolarmente i vecchi dati? Sì, a condizione di rispettare gli obblighi legali di conservazione. Documenti contabili, fatture, dichiarazioni devono essere conservati per le durate legali applicabili. Per contro, log tecnici, sessioni, file temporanei e allegati obsoleti possono essere archiviati o eliminati senza rischio, con un guadagno di prestazioni notevole.
Il passaggio a PostgreSQL apporterebbe un guadagno? PostgreSQL è un eccellente motore di database e Dolibarr può girare su PostgreSQL. Il guadagno puro in prestazioni non è sistematico: MySQL/MariaDB ben configurato resta molto performante per il profilo di carico di Dolibarr. La scelta deriva più dalla strategia infrastrutturale e dalle competenze disponibili che da un vantaggio di prestazioni evidente.
I miei backup rallentano tutta l'applicazione, cosa fare? Un backup mal progettato blocca le tabelle e blocca gli utenti. Privilegia gli strumenti che eseguono backup a caldo senza bloccare, pianifica i backup completi al di fuori delle ore lavorative, usa la replicazione per scaricare i backup su una replica. Una strategia di backup ottimizzata preserva sia la sicurezza che le prestazioni.
Articolo redatto da NEXT GESTION, esperto Dolibarr e accompagnamento delle aziende sull'ottimizzazione, la sicurezza e l'evoluzione del loro ERP/CRM. Vuoi auditare le prestazioni della tua istanza Dolibarr? Contatta i nostri consulenti: contact@nextgestion.com.