Throughput

Il throughput è la quantità di lavoro che un sistema porta a termine per unità di tempo: richieste al secondo (RPS) per un’API, transazioni al secondo (TPS) per un sistema di pagamento, messaggi al secondo per un consumer di una coda. Misura la capacità, mentre la latenza misura quanto tempo richiede ogni singola unità di lavoro. Ti servono entrambe, più il tasso di errore, per descrivere le performance.

Come si legano throughput, latenza e concorrenza

Per un sistema stabile, la legge di Little collega le tre grandezze:

concurrent requests in flight = throughput × average response time

Example: 200 requests/second × 0.25 seconds = 50 requests in flight

Con utenti virtuali che fanno una pausa tra un’azione e l’altra, il think time si aggiunge al ciclo: throughput ≈ utenti ÷ (tempo di risposta + think time). Quindi 100 utenti con un tempo di risposta di 0,5 s e 4,5 s di think time generano circa 20 richieste al secondo, non 100. Ecco perché “abbiamo testato con 1.000 utenti” significa poco finché non indichi anche il think time e il tasso di richieste risultante.

Come si comporta il throughput con un carico crescente

All’aumentare del carico, il throughput inizialmente cresce di pari passo. A un certo punto una risorsa si satura (CPU, un pool di connessioni, un componente single-thread) e il throughput si appiattisce mentre la latenza sale in modo ripido. Spingendo ancora, il throughput può addirittura calare, perché il sistema spende le sue energie in code, retry e timeout. Trovare quel plateau è il risultato principale di uno stress test e definisce la capacità pratica.

Consigli per i test

• Esprimi gli obiettivi come tasso più latenza. “500 RPS con p95 sotto i 300 ms e meno dell’1% di errori” è testabile. “Regge traffico elevato” no.
• Conta solo il lavoro riuscito. Un server che risponde a 2.000 RPS con metà delle risposte in errore 500 non sta facendo 2.000 RPS di lavoro utile.
• Usa un carico basato sull’arrival rate quando possibile. Generare un tasso di richieste fisso mostra direttamente se il sistema riesce a sostenerlo; un pool fisso di utenti invierà silenziosamente meno richieste man mano che le risposte rallentano.
• Controlla il generatore di carico. Se la macchina che esegue il test è al 100% di CPU, hai misurato il throughput del generatore, non quello del sistema.
• Attenzione ai rate limit. Un gateway che restituisce 429 limita il throughput misurato; decidi se stai testando il limiter o il servizio dietro di esso.