All'inizio il gestionale era veloce. Poi, anno dopo anno, qualcosa è cambiato: le ricerche impiegano secondi, a volte minuti; quando qualcuno lancia un report si blocca tutto; il lunedì mattina è un incubo. La prima reazione è spesso «serve un server più potente». A volte è vero. Molto più spesso la causa è altrove, e un server nuovo sposta il problema di qualche mese.
Ecco le sette cause più comuni di un gestionale lento, come riconoscerle dai sintomi e cosa si può fare.
1. Mancano gli indici giusti nel database
Un indice è per il database quello che l'indice analitico è per un libro: permette di trovare un dato senza sfogliare tutte le pagine. Se manca, ogni ricerca legge l'intera tabella. Con pochi dati non si nota; con dieci anni di fatture sì.
Sintomo tipico: le ricerche e le liste peggiorano lentamente con il passare del tempo, anche se il numero di utenti non cambia.
2. Query scritte male
Il software chiede i dati al database attraverso delle interrogazioni (query). Alcuni errori sono frequenti: chiedere tutti i campi quando ne servono due, ripetere centinaia di piccole richieste invece di una sola, filtrare i dati nel programma invece che nel database.
Sintomo tipico: una schermata specifica è lenta anche quando il resto del programma va bene.
3. Report pesanti sullo stesso database delle operazioni
Un report che analizza un anno di vendite può impegnare il database per minuti. Se gira sullo stesso database su cui tutti lavorano, rallenta tutti.
Sintomo tipico: il programma si blocca per tutti quando qualcuno lancia un report o un'esportazione. Le soluzioni vanno dallo spostare i report in orari tranquilli a usare una copia del database dedicata alle analisi.
4. Tabelle che crescono senza manutenzione
Log mai cancellati, storici mai archiviati, statistiche del database mai aggiornate: tutto si accumula. Molti database hanno bisogno di una manutenzione periodica per restare efficienti, e spesso nessuno l'ha mai pianificata.
Sintomo tipico: il programma rallenta un po' ogni anno, senza un momento preciso in cui «si è rotto».
5. Blocchi e transazioni lunghe
Quando un'operazione modifica dei dati, il database li «blocca» finché non ha finito, per evitare conflitti. Se un'operazione dura troppo, gli altri utenti restano in attesa.
Sintomo tipico: va tutto bene la mattina presto e rallenta quando lavorano tutti; compaiono errori di timeout o messaggi di record bloccato.
6. Server sottodimensionato o configurato male
Esiste anche la causa che tutti sospettano: poca memoria, dischi lenti, database configurato con le impostazioni predefinite che non sfruttano le risorse disponibili. Ma va verificata con i numeri, non a sensazione.
Sintomo tipico: memoria o disco del server costantemente al limite, anche nelle operazioni semplici.
7. Rete e architettura
Alcuni gestionali sono stati pensati per funzionare in rete locale e vengono usati da sedi remote attraverso una VPN. Ogni schermata scambia moltissimi dati con il server e la distanza si fa sentire. Lo stesso accade quando il programma aspetta la risposta di un servizio esterno lento.
Sintomo tipico: in sede va bene, da fuori è lentissimo; oppure è lento solo nelle operazioni che dialogano con altri sistemi.
Dal sintomo alla causa
| Cosa noti | Causa probabile |
|---|---|
| Peggiora piano piano negli anni | Indici mancanti, tabelle senza manutenzione |
| Una sola schermata è lenta | Query scritte male in quel punto |
| Si blocca quando qualcuno lancia un report | Report sullo stesso database delle operazioni |
| Rallenta nelle ore di punta, errori di timeout | Blocchi e transazioni lunghe |
| Lento solo da una sede o da remoto | Rete e architettura |
| Server sempre al limite delle risorse | Server sottodimensionato o mal configurato |
Come capire quale causa ti riguarda
La regola è una sola: prima si misura, poi si interviene. Concretamente:
- annota quali operazioni sono lente, quanto durano, a che ora e da quale postazione;
- attiva sul database il registro delle interrogazioni lente (tutti i principali database ne hanno uno, per esempio lo slow query log in MySQL o pg_stat_statements in PostgreSQL);
- controlla l'uso di processore, memoria e disco del server nelle ore critiche;
- confronta: se le risorse del server sono tranquille ma alcune query durano secondi, il problema è nel database o nel codice, non nell'hardware.
Perché un server più potente spesso non basta
Se la causa è un indice mancante, un server due volte più veloce dimezza l'attesa. Ma i dati continuano a crescere e in poco tempo si torna al punto di partenza, con un costo in più. Aggiungere l'indice giusto, invece, può rendere la stessa ricerca decine di volte più veloce, e il miglioramento resta anche con dati in crescita.
Un dato per capire quanto vale intervenire: dieci persone che aspettano due minuti venti volte al giorno sono quasi sette ore di lavoro perse ogni giorno.
In sintesi
Un gestionale lento quasi sempre ha una causa precisa, e spesso non è il server. Misura, individua il collo di bottiglia, intervieni lì. Se vuoi farlo con un aiuto esterno, ci occupiamo proprio di questo: analizziamo query, database, codice e server e correggiamo dove serve, senza riscrivere quello che funziona. La prima consulenza è gratuita.