La tua applicazione funziona perfettamente con dieci utenti. Cosa succede il giorno dei saldi, con diecimila? Test di carico e test di stress descrivono due diversi modi per rispondere e mescolarli porta a test che non dimostrano ciò che pensi che facciano.

Questa guida spiega cosa mostra ciascuno, i relativi tipi di test e come leggere i risultati. Abbiamo eseguito il calcolo del piccolo percentile riportato di seguito su Python 3.13, con numeri simulati. Gli script k6 sono esempi illustrativi che non abbiamo eseguito e i conteggi degli utenti e gli obiettivi sono inventati, quindi sostituiscili con i tuoi. Esegui questi test solo su sistemi di tua proprietà o che sei autorizzato a testare, poiché il traffico intenso può sembrare un attacco e causare interruzioni reali.

La risposta breve

Un test di carico chiede: possiamo gestire il traffico che ci aspettiamo e raggiungere i nostri obiettivi mentre lo facciamo? Uno stress test chiede: quanto possiamo sopportare prima di fallire, come falliamo e quanto velocemente ci riprendiamo?

Pensa a un ponte. Un test di carico fa attraversare il numero previsto di camion e conferma che va bene. Uno stress test continua ad aggiungere peso per conoscere il suo limite e se dà prima un avvertimento. Fortunatamente, è più economico rompere un software che un ponte.

Test di carico e test di stress fianco a fianco

Cos’è il test di carico?

Il test di carico simula il traffico realistico previsto e misura il comportamento del sistema. Ha bisogno di un obiettivo rispetto al quale effettuare il test, ad esempio: “con 500 utenti simultanei, il 95% delle richieste di pagamento termina entro 800 ms, con errori inferiori all’1%”.

Ecco come potrebbe apparire come uno script k6. I test k6 sono scritti in JavaScript e thresholds trasformano i tuoi obiettivi in un risultato superato o fallito:

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  stages: [
    { duration: "5m", target: 500 },   // ramp up
    { duration: "20m", target: 500 },  // hold at expected peak
    { duration: "2m", target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ["p(95)<800"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/products");
  sleep(1);   // think time, as real users pause
}

Il sleep conta. Senza tempo per pensare, ogni utente virtuale martella continuamente il server, producendo molto più traffico di quanto farebbe lo stesso numero di persone reali.

Cos’è lo stress test?

Gli stress test vanno deliberatamente oltre i livelli attesi. Non stai cercando di passare. Vuoi risposte a domande come:

• A quale livello le prestazioni iniziano a crollare?
• Quale componente si guasta per primo: il database, i server delle applicazioni o una chiamata di terze parti?
• Fallisce correttamente con errori evidenti o si blocca e perde dati?
• Si riprende da solo quando il traffico diminuisce?

export const options = {
  stages: [
    { duration: "5m", target: 500 },    // expected peak
    { duration: "5m", target: 1000 },   // beyond it
    { duration: "5m", target: 2000 },   // further
    { duration: "5m", target: 4000 },   // likely to break
    { duration: "10m", target: 0 },     // recovery: does it come back?
  ],
};

La fase finale del recupero viene spesso dimenticata e potrebbe essere quella più preziosa. Un sistema che gestisce bene i guasti ma non si ripristina mai senza un riavvio manuale significa comunque un’interruzione che qualcuno deve riparare nel cuore della notte. Idealmente, in condizioni di carico estremo, un sistema dovrebbe ridurre il lavoro in modo controllato, restituendo chiare 503 risposte invece di andare in timeout.

Spike, ammollo e altri tipi

I test di carico e di stress appartengono a una famiglia più ampia di test delle prestazioni:

I test di assorbimento rilevano problemi che i test brevi non vedono mai. Una piccola perdita di memoria può sembrare innocua per venti minuti e interrompere il servizio solo dopo due giorni. I test di picco sono adatti a eventi come le vendite flash, in cui il traffico non aumenta gradualmente.

Metriche che contano

Perché le medie ingannano

Le medie nascondono le richieste lente di cui le persone reali si lamentano. Per dimostrarlo, abbiamo generato 100 tempi di risposta simulati, di cui 95 rapidi (da 80 a 200 ms) e 5 molto lenti (da 2,5 a 4 secondi), quindi abbiamo calcolato le statistiche comuni:

import math, random, statistics

random.seed(3)
times = [random.randint(80, 200) for _ in range(95)] \
      + [random.randint(2500, 4000) for _ in range(5)]

def pct(values, p):
    values = sorted(values)
    return values[math.ceil(p / 100 * len(values)) - 1]

print("avg", round(statistics.mean(times)), "p50", pct(times, 50),
      "p95", pct(times, 95), "p99", pct(times, 99), "max", max(times))

# avg 302 p50 150 p95 199 p99 3740 max 3896

Osserva attentamente quei numeri. La media di 302 ms non descrive nessuno. Le richieste tipiche impiegavano circa 150 ms, mentre quelle lente impiegavano più di 3 secondi. Anche p95 sembra in buone condizioni con 199 ms, e solo p99 rivela il problema. Una cifra come p95 significa che il 95% delle richieste erano così veloci o più veloci.

E l’1% delle richieste non è un evento raro. Se una pagina effettua 50 richieste, un p99 lento influisce su un’ampia percentuale di visualizzazioni di pagina. Stabilisci obiettivi sui percentili che ti interessano e esaminane diversi insieme.

Strumenti

Ognuno di questi può eseguire sia test di carico che di stress. Scegli quello che si adatta alle competenze del tuo team, piuttosto che rincorrere un elenco di funzionalità. Per utilizzarne uno nella tua pipeline, vedi cos’è CI/CD.

Come pianificare un test

1. Fissa obiettivi. Utilizza analisi reali per trovare il traffico di punta e definire obiettivi.
2. Scegli i viaggi. Modella il comportamento realistico degli utenti, come navigazione, ricerca e pagamento, in proporzioni realistiche. Colpire solo la home page dimostra poco.
3. Utilizza un ambiente realistico. Un piccolo server di staging non può prevedere la produzione. Nota eventuali differenze.
4. Prepara i dati. Utilizza volumi realistici, perché una query veloce su 100 righe può eseguire la scansione su 10 milioni.
5. Avvisa le persone. Informa il tuo team operativo e eventuali terze parti e non caricare per sbaglio il test di un fornitore di servizi di pagamento. Derisione di servizi esterni ove appropriato.
6. Inizia in piccolo. Esegui prima un piccolo test del fumo per confermare che lo script funziona.
7. Monitora tutto. Senza le metriche del server, vedrai che è rallentato, ma non il perché.
8. Ripeti. Eseguilo di nuovo dopo ogni correzione e mantieni una base di riferimento con cui confrontarla.

Leggere i risultati

I database rappresentano un collo di bottiglia comune, quindi se il problema sono le query, leggi la nostra guida all’ottimizzazione delle query SQL. L’ultima riga della tabella è una trappola importante: controlla sempre anche lo stato della macchina che genera il carico.

Errori comuni

• Confondere gli utenti con le richieste. Sii chiaro se un target indica utenti simultanei o richieste al secondo.
• Tralasciare il tempo per pensare. Ciò aumenta il traffico e fornisce risultati fuorvianti.
• Test troppo tardi. Una settimana prima del lancio non lascia tempo per risolvere i problemi di architettura.
• Utilizzo di un singolo endpoint. Il traffico reale combina letture, scritture e ricerche.
• La memorizzazione nella cache nasconde tutto. Richieste identiche ripetute possono solo testare la cache, quindi varia i dati.
• Testare una volta. Le prestazioni cambiano con ogni versione, quindi esegui i test regolarmente.

Considerazioni finali

Esegui test di carico per confermare che sei in grado di gestire il traffico previsto e test di stress per scoprire cosa succede quando non puoi. Inizia in piccolo: scegli il percorso utente più importante, stabilisci un obiettivo chiaro ed esegui un breve test rispetto alla fase di staging con il monitoraggio attivo. Quella prima esecuzione di solito ti insegna qualcosa e puoi costruire da lì.

Domande frequenti

Continua a imparare