Stress testing

Lo stress testing spinge deliberatamente un sistema oltre il carico previsto, un passo alla volta, finché non smette di rispettare i suoi obiettivi o cede del tutto. Dove un test di carico chiede “reggiamo il picco normale?”, uno stress test chiede “quanto possiamo sopportare, cosa si rompe per primo e cosa succede agli utenti quando accade?”.

Esempio (k6 con arrival rate crescente)

Aumentare il tasso di richieste a gradini, indipendentemente da quanto velocemente risponde il server:

import http from 'k6/http';

export const options = {
  scenarios: {
    breakpoint: {
      executor: 'ramping-arrival-rate',
      startRate: 50,
      timeUnit: '1s',
      preAllocatedVUs: 200,
      maxVUs: 2000,
      stages: [
        { duration: '5m', target: 200 },
        { duration: '5m', target: 400 },
        { duration: '5m', target: 800 },
        { duration: '3m', target: 0 }, // ramp down to observe recovery
      ],
    },
  },
};

export default function () {
  http.get('https://staging.example.com/api/search?q=shoes');
}

Un executor basato sull’arrival rate continua a inviare richieste al tasso obiettivo anche quando le risposte rallentano, il che è più vicino agli utenti reali e mette in luce la saturazione più chiaramente di un numero fisso di utenti virtuali.

Cosa osservare

• Il ginocchio. Il tasso al quale i percentili di latenza iniziano a salire bruscamente mentre il throughput si appiattisce. Quella è la tua capacità pratica.
• La modalità di guasto. Un degrado controllato si presenta come risposte 429 o 503 rapide e carico scartato. Un guasto grave si presenta come timeout, guasti a cascata in altri servizi, dati corrotti o processi andati in crash.
• Il recupero. Dopo la fase di discesa, la latenza torna normale da sola o servono riavvii per connessioni bloccate e code piene?
• Il primo collo di bottiglia. CPU, pool di connessioni al database, pool di thread, memoria o una dipendenza a valle. Risolverlo sposta il punto di rottura, per questo gli stress test vengono spesso ripetuti.

In cosa differisce dallo spike testing

Uno stress test aumenta il carico gradualmente per trovare un limite. Uno spike test salta quasi istantaneamente da un carico normale a uno molto alto, ad esempio durante una vendita lampo o dopo una notifica push, e verifica se autoscaling e code reagiscono abbastanza in fretta.

Errori comuni

Eseguire stress test su ambienti condivisi da cui dipendono altri team, eseguirli da un unico generatore di carico che si satura prima del server e fermarsi a “si è rotto a 800 rps” senza registrare come si è rotto e se si è ripreso.