Latenza

La latenza è il tempo tra l’invio di una richiesta e l’arrivo della risposta. Nei sistemi di rete si misura in millisecondi; nei sistemi distribuiti a volte in microsecondi; nella latenza percepita dall’utente, nelle centinaia di millisecondi in cui gli esseri umani iniziano a notare.

Tre misurazioni che ogni ingegnere dovrebbe conoscere sulla latenza di un servizio:

• Latenza media. Solitamente fuorviante. Un singolo outlier lento la trascina in alto.
• Latenza mediana (p50). L’esperienza della richiesta tipica. Più onesta della media.
• Latenze di coda (p95, p99, p99,9). Il 95°, 99°, 99,9° percentile dei tempi di risposta. p99 significa “l’1% delle richieste è più lento di questo.” Per i sistemi rivolti agli utenti, p99 cattura l’esperienza degli utenti sfortunati.

Perché le code contano: su scala, ogni utente colpisce la coda alla fine. Un servizio con p50 a 100 ms e p99 a 5000 ms ha prestazioni tipiche veloci e congelamenti occasionali di 5 secondi. Un utente che fa 100 richieste in una sessione probabilmente colpirà la coda almeno una volta.

Fonti di latenza in una tipica richiesta HTTP:

• DNS: 1-50 ms primo lookup, ~0 in cache.
• Handshake TCP: 1 round-trip time (RTT).
• Handshake TLS: 1-2 RTT aggiuntivi.
• Elaborazione server: altamente variabile, da microsecondi a secondi.
• Propagazione di rete: ~5 ms NY-Chicago, ~70 ms NY-Londra, ~150 ms NY-Sydney. Il limite inferiore è la velocità della luce.

Per le prestazioni API nel mondo reale, la distribuzione per percentile conta molto più della media. Riportare solo la latenza media è uno dei modi classici in cui i dashboard di monitoraggio ingannano.

Perché p99 è la metrica che definisce “sembra rotto”: un servizio con il 99% delle richieste sotto 100 ms ma l’1% che impiega 5 secondi sembra rotto a ogni utente che alla fine colpisce il percorso lento. La matematica: se un tipico caricamento di pagina fa 50 chiamate backend e p99 è 5 s, la probabilità che l’utente colpisca almeno una chiamata lenta è 1 − (0,99)⁵⁰ ≈ 40%. Quasi ogni altro caricamento di pagina è lento. Migliorare la mediana è invisibile; ridurre p99 migliora direttamente le prestazioni percepite. Il manuale SRE di Google ha codificato questo principio (“la latenza di coda è la latenza”), e la convenzione si è diffusa in tutto il settore. Riferimento: Dean & Barroso — The Tail at Scale (CACM, 2013).

Esempio pratico: allocazione del budget su una richiesta

Obiettivo: 200 ms p95 per una pagina di checkout da un utente statunitense. L’RTT NY-Londra alla velocità della luce è circa 70 ms; questo è il pavimento per qualsiasi chiamata transatlantica. Un fanout tipico: 50 ms TLS + risparmi di riutilizzo connessione, 40 ms lettura DB regionale, 60 ms autorizzazione pagamento di terze parti, 20 ms rendering HTML, 30 ms idratazione lato client. Sommare queste naively dà 200 ms — lasciando zero margine per retry, pause GC o picchi di vicini rumorosi. La soluzione è strutturale: sposta la chiamata di pagamento fuori dal percorso critico (differita a post-redirect), metti in cache la lettura DB all’edge per 60 s, e usa HTTP/3 su QUIC per incorporare TLS nella configurazione della connessione. Ognuno taglia 30-50 ms dalla coda.

Come strumentarlo correttamente

Aggregare per media scarta la stessa forma della distribuzione di cui hai bisogno. Campiona i tempi grezzi o usa istogrammi HDR (la libreria HdrHistogram di Gil Tene, portata alla maggior parte dei linguaggi) che preservano i percentili economicamente. Calcola i percentili per regione, per endpoint, per release — una regressione globale di p99 da 5 ms può significare una regressione di 200 ms in una singola regione mascherata dalla media. Attenzione all’“omissione coordinata”: i generatori di carico che aspettano una richiesta lenta prima di emettere la successiva sottostimano p99 di ordini di grandezza. Vedi anche percentile e mediana. Per la suddivisione RTT a livello di protocollo, la specifica RFC 9000 QUIC documenta l’instaurazione di connessioni 0-RTT e 1-RTT che riduce materialmente la latenza dell’handshake.