Cos'è e perché conta
Un'app fatta con Claude Code funziona benissimo con te e tre amici. Poi arrivano cento persone nello stesso momento e le pagine ci mettono un'eternità, o non si aprono proprio.
Il motivo di solito non è il server piccolo. È il modo in cui l'app parla con il database. Con pochi dati e pochi utenti ogni spreco costa millisecondi. Con tanti dati e tante persone insieme, gli sprechi si sommano.
La prova di carico serve a vederlo prima: simuli tante persone insieme, misuri quanto ci mette ogni pagina e scopri cosa si rompe. Prima tu che i tuoi utenti.
Regola numero uno, senza eccezioni: la prova si fa su una copia del progetto o sull'ambiente di prova (staging), con dati finti. Mai sul database con i dati veri, mai sul sito in produzione. Una prova di carico è un piccolo attacco: sul sito vero rallenti o butti giù l'app per chi la sta usando.
1. Prepara il posto giusto
Prima di scrivere il prompt mi assicuro di tre cose.
- Ho una copia separata: un ambiente di prova, o il progetto sul mio computer con un database tutto suo.
- Ho fatto un commit con git, per poter tornare indietro.
- So quali servizi esterni usa l'app (pagamenti, email, notifiche, API di altri). Nella prova non vanno chiamati davvero.
Sull'ultimo punto: una prova di carico contro un sito o un'API che non sono tuoi può violare le loro condizioni d'uso. Prova solo il tuo ambiente di prova. Per partire, chiedo a Claude di controllare:
Prima di tutto controlla a quale database e a quali servizi esterni è collegato il progetto in questo momento. Se qualcosa punta ai dati veri o alla produzione, fermati e dimmelo. Voglio fare la prova solo su una copia, con dati finti, e con i servizi esterni sostituiti da versioni finte.
2. La prova con mille utenti finti
Poi in Claude Code scrivo questo:
Fai una prova con mille utenti finti e dimmi cosa si rompe. Riempi il database di prova con dati finti realistici, scrivi uno script che simula mille persone sulle pagine principali nello stesso momento (usa uno strumento gratuito e open source, per esempio k6, Locust o Artillery) e misura quanto ci mette ogni pagina. Dammi le tre pagine più lente, il motivo e la correzione che proponi. Non toccare il codice finché non ti dico ok.
Cosa succede, in pratica. Claude riempie il database di prova con tante righe finte ma credibili: utenti, ordini, prodotti. Conta più di quanto sembri: con dieci righe tutto è veloce, i problemi escono solo con volumi realistici.
Poi scrive uno script che manda richieste alle pagine principali come se fossero tante persone insieme. k6, Locust e Artillery sono tre strumenti gratuiti e open source che fanno proprio questo: lascia che scelga Claude in base al progetto.
L'ultima frase è la più importante: prima voglio capire, poi decido. Lo script della prova e i dati finti li deve creare, il codice dell'app no.
Per una garanzia in più mentre ti propone le correzioni, usa il plan mode: Shift+Tab finché in basso vedi «plan mode on», oppure /plan all'inizio del messaggio. Lì Claude legge e propone, ma non modifica i file finché non approvi il piano. Per la prova invece restane fuori: deve creare script e dati finti.
Mille subito o a scalini
Mille persone insieme sono tante, anche per il computer che genera la prova. Meglio salire a scalini e vedere a che punto le pagine rallentano. E l'ambiente di prova di solito è più piccolo di quello vero: conta il prima e dopo, non il numero assoluto.
Fai la prova a scalini: prima 50 utenti, poi 200, poi mille. Per ogni scalino dimmi il tempo medio, il tempo delle richieste più lente e da che punto iniziano gli errori.
Una correzione alla volta
Quando ti dà l'elenco delle tre pagine più lente, non chiedere di sistemare tutto insieme. Scrivi:
Correggi la prima, rifai la prova e dimmi i tempi prima e dopo.
E così via con la seconda e la terza. Se correggi tutto in un colpo e poi qualcosa migliora, o peggiora, non sai cosa è stato.
3. Le tre cose che sistema quasi sempre
Quando una pagina è lenta, il motivo quasi sempre è uno di questi tre.
Cento domande invece di una
Una pagina mostra 100 prodotti. Il codice prima chiede al database la lista dei prodotti, poi, per ognuno, chiede il prezzo. Totale: 101 domande al database per una pagina sola. Si chiama «problema N+1»: una domanda per la lista, più una per ogni elemento.
Da solo non lo noti. Con mille persone diventano centomila domande, e il database si intasa. E spesso il codice sembra pulito: il problema è dietro.
La correzione è chiedere tutto insieme: una domanda sola che prende prodotti e prezzi, o al massimo due (la lista, poi tutti i prezzi in un colpo). Chiedi:
Trova le query dentro un ciclo e trasformale in una sola.
Tabelle senza indici
Pensa all'indice in fondo a un libro. Senza, per trovare una parola sfogli tutte le pagine. Il database fa lo stesso: senza indice, per trovare gli ordini di un utente li legge tutti, uno per uno. Con l'indice va dritto.
Di solito l'id principale di ogni tabella ha già il suo indice. Le colonne che usi per cercare, filtrare e collegare le tabelle, spesso no. Chiedi:
Aggiungi gli indici sulle colonne che usi per cercare, filtrare e ordinare (id dell'utente, email, data).
Gli indici però non sono gratis: occupano spazio e rendono un po' più lente le scritture, perché a ogni dato nuovo il database aggiorna anche l'indice. Vanno messi solo dove servono. Io chiedo sempre la prova:
Per ogni indice che aggiungi, dimmi quale pagina o query lo usa e mostrami il tempo prima e dopo. Se un indice non serve a niente, non aggiungerlo.
Dati ricaricati ogni volta
Il listino o il menu che cambiano una volta al giorno non vanno chiesti al database a ogni visita. Si tengono in memoria per qualche minuto: è la cache.
Metti in cache i dati che cambiano raramente e dimmi dopo quanto si aggiornano.
Anche la cache ha un prezzo: i dati possono essere vecchi. Se cambi un prezzo e la cache dura dieci minuti, per dieci minuti qualcuno vede quello di prima. Per questo devi sapere dopo quanto si aggiornano. E i dati personali di un utente non devono finire in una cache condivisa, se no un altro rischia di vederli.
Controlla che nella cache non ci siano dati personali di un utente che un altro utente potrebbe vedere.
Attenzione se l'app gira su un hosting serverless: lì il codice gira su tante istanze che si accendono e si spengono da sole. La memoria di un'istanza non è condivisa con le altre e si svuota spesso, quindi una cache tenuta lì serve a poco. Ci vuole una cache condivisa, per esempio Redis. Chiedi a Claude quale offre il tuo hosting:
L'app gira su un hosting serverless? Se sì, dimmi quale cache condivisa offre il mio hosting e usa quella invece della memoria del server.
Gli errori più comuni
- Fare la prova sul sito vero o sul database con i dati veri. Si fa sempre su una copia o sull'ambiente di prova, con dati finti.
- Provare con il database quasi vuoto. Riempilo con dati finti in quantità realistiche.
- Correggere tutto in un colpo. Una correzione alla volta, con i tempi prima e dopo.
- Mettere indici su ogni colonna. Solo su quelle che usi per cercare, filtrare e ordinare.
- Una cache senza una scadenza chiara. Decidi dopo quanto si aggiorna e tienici fuori i dati personali.
Checklist
- Lavoro su una copia o sull'ambiente di prova, non sulla produzione
- Il database di prova ha dati finti in quantità realistiche
- Nella prova i servizi esterni sono finti
- Ho l'elenco delle tre pagine più lente, con motivo e correzione
- Ho corretto una cosa alla volta, con i tempi prima e dopo
- So dopo quanto si aggiorna ogni cache
Domande frequenti
Mille utenti sono tanti per la mia app?
Dipende. Mille iscritti non sono mille persone nello stesso momento: di solito chi usa l'app insieme è solo una parte. Mille in contemporanea è una prova dura, ed è il punto: vedi dove cede prima che succeda davvero.
Devo saper programmare per fare tutto questo?
No. Devi saper chiedere e leggere i risultati: quali pagine sono lente, perché, quanto migliorano dopo la correzione. Se una spiegazione non ti è chiara, chiedi a Claude di ripetertela con parole semplici prima di dire ok.