Soak testing (test di durata)

Il soak testing (chiamato anche endurance testing o test di durata) fa girare un sistema con un carico normale e costante per un lungo periodo, di solito diverse ore e a volte un giorno o più. Il carico in sé non ha niente di speciale; il punto è la durata. Molti difetti sono invisibili in un test di carico di 10 minuti perché crescono lentamente: qualche megabyte perso ogni mille richieste, una connessione che non viene mai restituita al pool, un file di log che riempie il disco.

Cosa trova

• Memory leak. Uso dell’heap che sale costantemente e non torna mai giù dopo la garbage collection, fino a finire in un crash per memoria esaurita.
• Esaurimento delle risorse. Connessioni al database, file handle, thread o socket aperti e mai rilasciati.
• Deriva graduale della latenza. Il p95 alla sesta ora è nettamente peggiore che alla prima, spesso a causa di cache che crescono, tabelle che si gonfiano o frammentazione.
• Interferenze dei job pianificati. Job batch notturni, backup, rinnovi dei certificati o rotazione dei log che si scontrano con il traffico reale.
• Crescita dello storage. Dischi che si riempiono di log, file temporanei o code arretrate.

Esempio (k6)

export const options = {
  stages: [
    { duration: '10m', target: 80 },
    { duration: '8h', target: 80 },
    { duration: '10m', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<600'],
    http_req_failed: ['rate<0.005'],
  },
};

La funzione di default è lo stesso percorso utente realistico che useresti per un test di carico. La differenza è la lunga fase stabile.

Come leggere i risultati

Un soak test si giudica dai trend, non solo dalle soglie pass/fail. Traccia memoria, numero di connessioni, percentili di latenza e tasso di errore su tutta l’esecuzione. Una linea piatta è un successo. Una pendenza costante verso l’alto è un difetto, anche se l’esecuzione è terminata prima che qualcosa andasse in crash, perché la produzione gira molto più a lungo di otto ore.

Errori comuni

• Eseguire il soak con un carico da stress test, mescolando due domande e rendendo poco chiara la causa di un fallimento.
• Guardare solo le metriche lato client. I leak si vedono prima nei grafici di memoria e dei pool lato server.
• Usare un ambiente che riavvia i servizi o li ridimensiona con l’autoscaling durante l’esecuzione, nascondendo proprio l’accumulo che stai cercando.
• Saltarlo perché è lento. Pianificalo di notte o nel weekend invece di eliminarlo.