Test di carico: cosa sono e perché il tuo sistema dovrebbe farli prima del client

Ogni sistema funziona bene con un utente. Il problema inizia con mille contemporaneamente.

La maggior parte dei team scopre il limite del proprio sistema nel peggior modo possibile: in produzione, durante i picchi, sotto gli occhi del cliente. La campagna esplode, l’articolo diventa virale, arriva la scadenza delle tasse, e quello che sembrava robusto crolla perché nessuno ha mai misurato quanto potrebbe durare.

Esistono test di carico per invertire questo ordine. Invece che l'utente trovi il limite per caso, lo trovi apposta, in un ambiente controllato, prima che faccia male.

Cos'è in realtà un test di carico

Il test di carico sottopone il sistema a un volume crescente di richieste o di utenti simultanei per misurare come si comporta sotto richiesta. La domanda a cui risponde non è “funziona?”, ma piuttosto “funziona con quanti?”.

Nota la differenza. Un test funzionale verifica che la funzionalità sia corretta. Un test di carico verifica che rimanga corretto e veloce quando molte persone lo utilizzano contemporaneamente. Queste sono domande diverse e la seconda appare solo in scala.

Simuli un numero realistico di utenti che eseguono azioni reali, accesso, ricerca, pagamento e osservi i tempi di risposta, il tasso di errore e l'utilizzo delle risorse all'aumentare del carico. Il risultato è un ritratto di come il sistema si degrada.

La differenza tra carico, stress e prestazione

Vale la pena separare i termini spesso confusi, perché ognuno risponde a una domanda diversa.

Il test di carico misura il comportamento in base alla domanda prevista e in aumento, quanti utenti simultanei il sistema supporta con una qualità accettabile. Gli stress test esagerano, di proposito, per vedere come il sistema si guasta e si riprende. I test delle prestazioni, in senso lato, misurano i tempi di risposta e l'efficienza, spesso sotto un certo carico.

Il carico risponde "può reggere come previsto?" Lo stress risponde "cosa succede in estremo?". Tenerli separati nella tua testa previene conclusioni sbagliate dal test sbagliato.

Perché questa è una decisione aziendale, non solo tecnica

È forte la tentazione di trattare il carico come un dettaglio ingegneristico. È un errore. Il limite di capacità del tuo sistema è il limite del numero di clienti che puoi servire contemporaneamente, e questo è puro business.

Immagina un servizio di pianificazione pubblico che apre i posti vacanti in un giorno specifico. L'intera popolazione ammissibile arriva entro la stessa finestra temporale. Se nessuno ha testato il carico, il sistema si blocca proprio quando conta di più e il guasto diventa notizia da prima pagina. Il costo non è tecnico; gode di fiducia istituzionalmente.

Lo stesso vale per una startup che prepara un lancio. Investire nei media per aumentare il traffico e avere il sito offline nel momento del picco significa bruciare due volte denaro: i media e la reputazione.

Cosa misurare e cosa nascondono le metriche

I parametri ovvi sono il tempo di risposta e il tasso di errore. Sono importanti, ma raccontano solo una parte della storia.

Il tempo medio è ingannevole. Una buona media può nascondere una frazione di utenti con un’esperienza terribile. Ecco perché guardo i percentili, il tempo in cui il 5% o l'1% ha vissuto la peggiore esperienza, piuttosto che le medie. È lì che sta la vera frustrazione.

Inoltre, guarda le risorse dietro: utilizzo della CPU, memoria, connessioni bancarie, coda delle richieste. Spesso il collo di bottiglia non è il server delle applicazioni, ma il database o un pool di connessioni di dimensioni insufficienti. Il test di carico non solo mostra che si è deteriorato; ben strumentato, mostra dove.

Gli errori più comuni

Il primo errore è testare in un ambiente che non assomiglia alla produzione. L'esecuzione di carichi su una macchina piccola o con una banca vuota genera numeri belli e inutili. L'ambiente di test deve essere rappresentativo e i dati devono avere un volume simile a quello reale.

Il secondo è simulare utenti irreali. Mille richieste identiche sullo stesso endpoint non riflettono il comportamento umano. Gli utenti reali navigano, pensano, ripetono azioni, abbandonano. Uno scenario di carico utile riproduce questo modello, non un robot uniforme.

Il terzo, e il più comune, è testare una volta, prima del lancio, e mai più. La capacità non è statica. Ogni nuova funzionalità, ogni nuova richiesta alla banca, può modificare il limite. I test di carico non ricorrenti hanno una validità breve.

Quando iniziare a preoccuparsi

Non tutti i sistemi necessitano di test di carico fin dal primo giorno. Un prodotto interno utilizzato da dieci persone non giustifica lo sforzo. La domanda giusta riguarda l’esposizione ai picchi.

Se il tuo sistema presenta momenti prevedibili di concentrazione della domanda, campagne, scadenze, lanci, stagionalità o rapida crescita della base, il test di carico non è più facoltativo. E il momento migliore per la prima misurazione è prima del primo grande picco, non dopo.

Il cambiamento di mentalità che sostengo è semplice: la capacità è un requisito, non una sorpresa. Conoscere il limite massimo del tuo sistema è importante quanto sapere se fa ciò che promette. Uno ti dice che funziona; l'altro ti dice per quanto tempo continuerà a funzionare quando arriverà il successo.

Se la vostra organizzazione ha un evento di picco all’orizzonte e nessuno sa con certezza se il sistema sarà in grado di gestirlo, questo è il tipo di rischio che vale la pena affrontare in anticipo, non durante. Ho altri testi sul blog su prestazioni, scalabilità e affidabilità che parlano di questo.