Introduzione
La Digital Experience, (vedi articoli specifici nel blog), è spesso valutata utilizzando metriche ottenute dall’analisi passiva del traffico, in particolare lo User Response Time è la metrica che ne esprime la sintesi.
Lo User Response Time ha l’obiettivo di evidenziare ciò che un utente percepisce, partendo dal momento in cui inizia una transazione sino al momento in cui quella transazione si conclude, quindi indica il tempo complessivo per l’esecuzione di una specifica transazione,.
Lo User Response Time è costituito dalle seguente sotto-metriche :
– Connection Setup Time
– Request Payload Transfer Time
– Response Payload Transfer Time
– Server Response Time
– Retransmission Delay
Il tempo complessivo è dunque influenzato dal contributo di tutte le latenze che si esprimono tra il client e l’applicazione, latenze che possono variare nel tempo per svariati motivi e che possono impattare lo User Response Time in maniera più o meno significativa.
Molto spesso le aziende/organizzazioni adottano soluzioni specifiche di APM a livello applicativo e soluzioni di network monitor che oltre ad analizzare il traffico di rete, ne misurano anche il packet loss ma non si preoccupano di correlare questi valori con quanto gli utenti percepiscono, ovvero analizzare l’incidenza degli stessi sullo User Response Time.
Stabilire delle soglie per ottenere un alert in caso di eventuale superamento, va bene ma non basta ad intercettare un problema sulla percezione che possono avere gli utenti nell’utilizzo di una specifica applicazione.
La percentuale di pacchetti persi/ritrasmetti di per se non indica il delay aggiuntivo che viene introdotto perché non considera la tipologia e la dimensione dei pacchetti persi.
Esempio pratico
Utilizziamo quale esempio, l’applicazione www.netperf.it, ovvero l’acceso al mio sito web istituzionale, misurato utilizzando la soluzione Alluvio AppResponse di Riverbed.
Il seguente grafico evidenzia la percentuale dei pacchetti totali ritrasmessi, in particolare evidenzia che il picco è di 4,21% alle 10:59 AM.
Grazie alle funzionalità di REST API, importiamo le metriche di interesse in un analytics come OpenSearch ed il grafico seguente evidenzia lo User Response Time.
Ovvero : 1.967,64 ms complessivi
– Connection Setup Time : 58,72 ms (3%)
– Request Payload Transfer Time : 1.552,50 ms (79%)
– Response Payload Transfer Time : 191,57 ms (9,7%)
– Server Response Time : 10,63 ms (0,54%)
– Retransmission Delay : 154,22 ms (7,8%)
E’ facilmente intuibile, basta guardare il grafico, come la metrica Retransmission Delay evidenzi valori significativi alle 10:59, alle 11:16 e alle 11:20, ma tramite i grafici seguenti, che ne evidenziano il valore nonchè l’incidenza, il tutto risulta molto più facilmente comprensibile.
In particolare :
Time % Total Retrans. Retrans. Delay Incidence 10:59 4,21 % 2.488 ms 80% 11:16 2,14 % 1.934 ms 59% 11:20 1,81 % 1.977 ms 60%
Conclusioni
Possiamo affermare quanto segue :
– la percentuale massima di ritrasmissioni è stata del 4,21%
– Il delay massimo introdotto dalle ritrasmissioni è stato di 2,488 sec
– L’incidenza massima del delay per ritrasmissioni sullo User Response Time è stata del 80%
Non è sufficiente monitorare la sola percentuale di packet loss, perchè il valore espresso non è contestualizzato all’applicazione ed alla tipologia e dimensione dei pacchetti coinvolti.
Una corretta strategia deve contemplare oltre che una soluzione di APM a livello applicativo anche una che sia in grado di correlare metriche tipicamente di network con la digital experience percepita dagli utenti, mediante una efficace analisi passiva del traffico.