Come misurare correttamente la latenza in sette minuti

Per misurare correttamente la latenza è necessario disporre di dati di qualità. Il Global CEO Outlook 2016 di KPMG (link esterno a ibm.com) ha rilevato che l'84% dei CEO sono preoccupati per la qualità dei dati su cui basano le decisioni, ed è perché i dati possono spesso essere fuorvianti.

La differenza tra le aziende che si preoccupano dei propri dati e quelle che non lo fanno è enorme. I ricercatori del MIT hanno scoperto (link esterno a ibm.com) che le aziende che hanno adottato un design basato sui dati hanno un output del 5-6% superiore a quello che ci si aspetterebbe visti gli altri investimenti e l'uso delle tecnologie dell'informazione. Solo per questo motivo, la comprensione della latenza è fondamentale per il successo aziendale.

In soli sette minuti imparerai tutto ciò che devi sapere sulla misurazione della latenza:

• Come misurare la latenza
• Perché è importante misurarla correttamente
• Errori comuni quando si esaminano i dati di latenza
• La criticità del feedback istantaneo
• Perché sono necessari dati non campionati

Dictionary.com (link esterno a ibm.com) definisce la latenza come “il periodo di ritardo quando un componente di un sistema hardware è in attesa che un'azione venga eseguita da un altro componente”. In termini più semplici, indica la quantità di tempo che intercorre tra la chiamata di una funzione e la sua effettiva esecuzione. La latenza è inerente a tutti i sistemi; anche se avessimo un sistema perfetto, che non esiste, sarebbe latente il tempo impiegato dagli elettroni del computer per accendere e spegnere i transistor o viceversa.

La latenza nelle piccole operazioni non è un grosso problema, ma quando si gestiscono milioni di operazioni, sono milioni le latenze che si vanno rapidamente a sommare. La latenza non è definita dalle unità di lavoro e dal tempo, ma dal suo comportamento. Gli strumenti di monitoraggio segnalano il tempo impiegato dall'inizio di una funzione alla fine della funzione.

La latenza può avere un impatto notevole sulla tua attività. Ad esempio (link esterno a ibm.com): «Quando si tratta di velocità mobile, ogni secondo è importante: per ogni secondo aggiuntivo necessario per caricare una pagina mobile, le conversioni possono diminuire fino al 20%».

La latenza non segue quasi mai una normale distribuzione gaussiana o di Poisson. Anche se la tua latenza segue una di queste distribuzioni, per come la misuriamo, le medie, le mediane e persino le deviazioni standard non servono a niente. Se, ad esempio, stai misurando il caricamento delle pagine, il 99,899% di questi caricamenti potrebbe essere peggiore della tua mediana. È uno dei motivi per cui il campionamento casuale della latenza causa dati imprecisi, ma ne parleremo più avanti.

A questo punto, probabilmente si starà chiedendo se non stiamo usando alcuna deviazione standard, come possiamo descrivere in modo significativo le latenze? La risposta è che dobbiamo considerare i percentili e i massimi. La maggior parte delle persone Think tra sé e sé: "Ok, quindi guardo P95 e capisco il "caso comune". Il problema di questo metodo è che il P95 nasconderà tutte le cose negative. Come afferma Gil Tene, CTO di Azul Systems: «È un 'sistema di marketing'. Qualcuno si sta facendo ingannare."

Prendiamo, ad esempio, questo grafico:

Guardando questo grafico, puoi capire chiaramente perché la mediana e la media non hanno un significato reale: non mostrano l'area problematica. Quando vedi il 95° percentile alzarsi verso sinistra, pensi di vedere il cuore del problema. Certo, non è vero, però. Quando indaghi sul motivo per cui il tuo programma ha avuto un singhiozzo, non riesci a vedere il peggior 5% di ciò che è successo. Per ottenere questo tipo di picco è necessario che il 5% dei dati più in alto sia significativamente peggiore.

Ora osserva lo stesso grafico che mostra anche il 99,99° percentile:

Quella linea rossa è il 95° percentile, mentre la linea verde è il 99,99° percentile. Come puoi vedere chiaramente, il 95° percentile mostra solo 2 su 22 dei tuoi problemi e il motivo per cui devi esaminare l'intero spettro dei tuoi dati.

Molte persone potrebbero pensare che l'ultimo 5% dei dati non abbia così tanta importanza. Certo, potrebbe trattarsi semplicemente del riavvio di una macchina virtuale (VM), di un problema nel sistema o qualcosa del genere, ma ignorandolo, stai dicendo che non succede quando potrebbe essere uno degli aspetti più importanti da prendere di mira.

Gil Tene ama affermare che “L'indicatore numero uno di cui non ci si dovrebbe mai sbarazzare è il valore massimo. Questo non è rumore, è il segnale. Il resto è rumore." Sebbene il massimo sia, in effetti, un ottimo singolo in un sistema su larga scala, spesso non è pratico perseguire solo il caso massimo. Nessun sistema è perfetto e si verificano intoppi. In un sistema pratico su larga scala, perseguire esclusivamente il caso massimo è spesso un buon modo per esaurire il suo team di sviluppo.

Quando si osserva il 99,99° percentile, si vede cosa succede alla maggior parte dei clienti e tutti i picchi che si vedono lì si sa che sono problemi reali, mentre eventuali picchi nel massimo potrebbero essere solo un intoppo nel sistema. Quando i tuoi team DevOps concentrano i loro sforzi su questi piccoli intoppi, lo fanno a un costo elevato, poiché non possono occuparsi di problemi più importanti.

È da notare che se il tuo 99,99° percentile e il tuo massimo sono molto vicini l'uno all'altro, e sono entrambi a picchi, allora è un ottimo segnale che si tratta di un problema su cui il tuo team dovrebbe lavorare. In questo modo, Gil ha ragione sul fatto che il massimo è un ottimo segnale, ma sbaglia sul fatto che il resto dei tuoi dati è solo rumore. Come può vedere in questo grafico, il nostro 99,99° percentile e il massimo del nostro esempio precedente corrispondono esattamente. È un ottimo segnale che quello che stai guardando è un vero bug e non solo un singhiozzo:

Una trappola ancora peggiore in cui le persone cadono, rispetto a quella di guardare solo il 95° percentile, è quella di non riconoscere che i loro percentili sono mediati. La media dei percentili è statisticamente assurda; Rimuove ogni significato da ciò che stai guardando. Abbiamo già mostrato come le medie non siano buone quando si guarda alla latenza e, se si guarda ai percentili medi, si torna semplicemente al punto di partenza. Molti programmi software calcolano la media dei percentili. Prendiamo, ad esempio, questo grafico di Grafana:

Che tu te ne sia accorto prima o no, tutti i percentili su questo grafico sono nella media. Lo dice proprio nel registro dell'asse x. Quasi tutti i servizi di monitoraggio fanno la media dei suoi percentili. È una realtà dovuta al precalcolo. Quando il servizio di monitoraggio acquisisce i dati, calcola il percentile dei dati per quel minuto.

Poi, quando guardi il tuo 95° percentile, ti mostra una media di tutti i tuoi percentili. Questa scorciatoia per "il tuo bene" volta a rendere il tuo servizio più veloce, in realtà, elimina ogni significato statistico dai tuoi dati.

Che tu lo sappia o meno, monitorando gli strumenti che partecipano al campionamento dei dati, producono dati medi. Quasi tutti gli strumenti di monitoraggio campionano i propri dati. Prendiamo, ad esempio, Datadog: ha una grave perdita di dati. Se invia loro 3 milioni di punti in un minuto, non li prenderanno tutti. Invece, campionerà i punti in modo casuale e li aggregherà in 1 punto al minuto.

Per comprendere la latenza è necessario disporre di dati non campionati. È intrinseco che con i dati campionati non può accedere alla distribuzione completa. Il tuo massimo non è il tuo vero massimo, né il tuo percentile globale è una rappresentazione accurata di ciò che sta accadendo.

Quando si campionano i dati, si omettono dei dati. Supponiamo, ad esempio, di avere 10.000 operazioni in corso in un minuto, inviando 2 punti dati ciascuno al sistema di monitoraggio. Supponiamo che nel tuo sistema ci sia un bug e che uno di questi punti dati mostri questo bug ogni 10.000 operazioni. Il suo sistema di monitoraggio ha solo 1/20.000 di possibilità di scegliere questo bug come dato massimo che Le mostra.

Se dura abbastanza a lungo, alla fine il dato verrà visualizzato ma, di conseguenza, sembrerà un caso edge sporadico, anche se succede a uno dei suoi clienti ogni minuto. Quando non si campionano i dati e si verifica uno di questi picchi, questi verranno visualizzati chiaramente nel 99,99° percentile e il massimo verrà visualizzato vicino ad esso, segnalando che si è verificato un bug nel programma. Quando campiona i suoi dati, tuttavia, non verranno visualizzati così spesso, il che significa che non li vedrà come un bug ma piuttosto come un intoppo. Questo risultato significa che il suo team di ingegneri non ne comprenderà l'importanza.

Non lasciare che il tuo strumento di monitoraggio ti inganni facendoti credere di sapere cosa sta succedendo con la tua latenza. Una delle caratteristiche principali del software IBM Instana™ è la sua capacità di misurare la latenza in modo efficiente. Il software IBM Instana utilizza l'analytics e il machine learning (ML) per rilevare automaticamente i problemi di latenza in tempo reale, consentendo agli sviluppatori e ai team IT di identificare rapidamente la causa principale di eventuali problemi di prestazioni e intraprendere azioni correttive prima che abbiano un impatto sugli utenti.

Scegli uno strumento che non fornisca dati campionati. Scegli uno strumento che non faccia la media dei tuoi percentili globali.