La web app va lenta. Gli utenti si lamentano, il team propone di aumentare le risorse del server. Le prestazioni migliorano per un po’, poi la lentezza ritorna. A quel punto qualcuno propone: "Riscriviamo tutto da zero."
Se questa sequenza ti è familiare, vale la pena considerare un’ipotesi che spesso viene sottovalutata: il collo di bottiglia non è (solo) l’infrastruttura, ma il modo in cui il codice interroga il database.
Non è sempre così. Ma succede molto più spesso di quanto si pensi.
Come funziona davvero il problema (spiegato semplice)
Ogni pagina che un utente apre richiede dati al database. È normale.
La differenza la fa quante richieste vengono fatte e come vengono fatte.
Immagina di dover mostrare una lista di 100 clienti con il loro ultimo ordine. Una persona andrebbe in archivio e prenderebbe tutte le informazioni necessarie in un’unica consultazione.
Un software scritto senza attenzione a questo aspetto può fare qualcosa di molto diverso: recupera l’elenco dei clienti, poi per ciascun cliente va a recuperare separatamente il suo ordine. Il risultato è lo stesso, ma il numero di accessi al database cresce rapidamente.
Questo schema è noto come problema N+1. È una delle cause più frequenti di lentezza nelle applicazioni data-driven: i dati sono corretti, ma il modo in cui vengono recuperati è inefficiente.
L’aspetto meno intuitivo è che il codice che produce questo comportamento può apparire perfettamente ordinato e conforme alle best practice del framework. Senza misurazioni, è facile non accorgersene.
Perché succede (e perché spesso non si vede)
Molti framework moderni — come Laravel, Symfony, Ruby on Rails o Django — incoraggiano l'uso di ORM e query builder. Strumenti molto utili, che permettono di lavorare in modo produttivo senza scrivere SQL a mano.
Il rovescio della medaglia è che, senza strumenti di osservabilità, diventa facile perdere visibilità su:
- quante query partono per una pagina,
- quanto tempo impiegano,
- come scalano al crescere dei dati.
Non è un limite degli strumenti in sé: è una questione di abitudini di monitoraggio. In molti team, queste metriche iniziano a essere guardate solo quando le prestazioni peggiorano in produzione.
Il risultato è un paradosso comune: codice pulito e idiomatico per il framework può generare accessi al database poco efficienti, se nessuno misura cosa succede davvero sotto.
I segnali d'allarme da tenere d'occhio
Non serve essere tecnici per intercettare alcuni indizi.
Le pagine diventano più lente col tempo
All'inizio tutto funziona bene. Con pochi utenti e pochi dati, anche query inefficienti hanno un impatto minimo. Con la crescita dei dati, le stesse query iniziano a pesare molto di più.
Se la lentezza aumenta insieme al volume di dati, è probabile che il problema sia nel modo in cui vengono recuperati, non nella quantità in sé.
I costi dei server crescono più del previsto
Quando i costi infrastrutturali aumentano più rapidamente del numero di utenti o del traffico, può essere un segnale di inefficienze applicative — spesso lato database. Non è una diagnosi automatica, ma è un indizio che vale la pena verificare con metriche.
Si tende a risolvere con infrastruttura e cache
Aumentare le risorse del server o introdurre cache può aiutare molto, e in molti casi è parte della soluzione. Tuttavia, se queste scelte vengono fatte senza aver prima misurato e compreso il carico sul database, si rischia di mascherare inefficienze strutturali invece di risolverle.
Quanto costa ignorare il problema
Studi di settore, come quelli divulgati da Google tramite Think with Google e analisi di Akamai Technologies, mostrano una correlazione chiara tra tempi di caricamento su mobile, aumento del bounce rate e calo delle conversioni negli e-commerce.
Il punto non è il numero esatto di secondi. È il principio: anche piccoli aumenti di latenza possono avere effetti misurabili sul comportamento degli utenti.
Sul piano tecnico, se il database sta gestendo un volume di query molto superiore al necessario, la crescita degli utenti rende il sistema sempre più difficile da scalare. A un certo punto, aumentare le risorse non è più sufficiente o diventa economicamente poco sostenibile.
C'è anche un effetto organizzativo: quando le prestazioni diventano un problema ricorrente, ogni nuova funzionalità viene percepita come un rischio, e lo sviluppo rallenta. È il classico scenario in cui il team diventa fragile e ha paura di deployare.
La domanda che chiarisce la situazione
Una domanda semplice aiuta a capire molto:
“Quante query fa la pagina principale?”
Se il team ha un numero aggiornato, significa che misura e osserva. Se la risposta è incerta, probabilmente questa dimensione non è sotto controllo.
Altre domande utili:
- Abbiamo visibilità sulle query per pagina/endpoint in produzione?
- Conosciamo la query più lenta e quanto tempo impiega?
- Le prestazioni sono peggiorate negli ultimi mesi?
Cosa puoi fare in pratica
Fase 1: Misura
L’obiettivo è ottenere visibilità su quante query vengono eseguite per pagina/endpoint e quanto tempo impiegano. In sviluppo bastano strumenti di debug; in produzione è preferibile un sistema di monitoring/APM che permetta di osservare i dati reali.
Fase 2: Identifica i punti critici
Con i numeri davanti, emergono subito le aree più costose: pagine con centinaia di query, endpoint lenti, report che stressano il database. È più efficace partire da questi casi che intervenire in modo generico.
Fase 3: Ottimizza le query più pesanti
Spesso una parte limitata di schermate o endpoint genera la maggior parte del carico. Intervenire su queste query — riducendo accessi ridondanti, introducendo join adeguati, verificando indici e piani di esecuzione — può avere un impatto significativo.
Fase 4: Prevenzione
Una volta sistemati i casi peggiori, è utile introdurre pratiche che evitino di ricadere nello stesso problema: metriche di performance visibili al team, attenzione alle query in code review, alert quando un endpoint supera certe soglie.
Quanto costa intervenire?
In molti casi, intervenire sulle query critiche richiede un effort contenuto rispetto ai benefici ottenuti, soprattutto quando il problema è concentrato in poche aree del prodotto. Non è una regola universale, ma è una situazione frequente nelle applicazioni cresciute nel tempo.
Senza questo lavoro, si finisce per compensare inefficienze con risorse sempre maggiori, fino a dover affrontare interventi molto più costosi e invasivi. O peggio, qualcuno propone di riscrivere tutto il monolite in microservizi quando il vero problema era nelle query.
La domanda chiave resta la stessa:
“Quante query fa questa pagina?”
Simone Giusti
Consulente software strategico
