Tempo di risposta sotto la lente degli esperti e dei professionisti DevOps (questo perché l’industria dello sviluppo software ha una vera ossessione per le metriche, in maniera a volte anche eccessiva). Quando si tratta di tempi di risposta dell’applicazione, tuttavia, le misurazioni sono utili.
Tempo di risposta: perché è così importante
I tempi di risposta delle applicazioni tendono a peggiorare progressivamente a causa della dilatazione del codice. Vero è che le aspettative dei clienti continuano a crescere e il customer care impone una riflessione adeguata. Eseguite correttamente, infatti, le misurazioni dei tempi di risposta delle applicazioni possono prevenire i reclami degli utenti ed evitare un decremento delle prestazioni.
Differenza tra tempo percepito e tempo funzionale
Conoscere gli standard relativi ai tempi di risposta delle applicazioni per un programmatore è fondamentale. Ma è necessario fare un distinguo tra percezione e funzione.
Bisogna ricordare come l’occhio umano riesca a percepire ritardi nell’ordine degli 0,25 secondi. Questo significa che se uno sviluppatore riduce la velocità di caricamento della pagina da 0,25 a 0,001 secondi, probabilmente spenderà dei soldi per miglioramenti che nessun cliente sarà in grado di apprezzare.
Gli insegnamenti di Google sul Web response time
Oltre 0,25 secondi, entriamo nel tempo di risposta relativo ad applicazioni reali. Alcune organizzazioni scelgono di intervistare i clienti per fissare le aspettative. Altri si affidano a un nuovo criterio ispirato al metodo Google, che sulla velocità di caricamento della pagina come fattore di classificazione ha creato un mantra per la programmazione. Utilizzare le metriche di usabilità per aiutare a classificare le pagine, infatti, è diventata una priorità. I siti lenti, infatti, riducono la soddisfazione del cliente e le ricerche confermano come un miglioramento della velocità del sito possa aumentare il tasso di conversione.
La variabile del caricamento delle pagine
Esistono decine di strumenti che misurano i tempi di caricamento delle pagine, dai semplici plug-in del browser ai complessi software basati su cloud che valutano le prestazioni end-to-end con l’accesso al sito da una dozzina di posizioni.
Il consiglio degli esperti è di cercare di mantenere le misurazioni il più realistiche ma anche end-to-end possibili. Il principio end-to-end, infatti, è quello secondo cui in presenza di due applicazioni che comunicano tramite una rete, tutte le funzioni e le operazioni richieste devono essere utilizzate ed eseguite in modo completo nei nodi (o end point) e non nei nodi intermedi della rete, per evitare di non soddisfare i requisiti delle applicazioni o penalizzare le applicazioni presenti su altri nodi della rete.
Tempo di risposta e latenza: che differenza c’è?
Le prestazioni di un’applicazione sono legate alla somma di tutte le componenti di un sistema. Una volta completate le misurazioni, è necessario considerare due variabili: la latenza e il tempo di risposta.
- La latenza è il tempo che serve a spostare un messaggio dal server al client
- Il tempo di risposta è il tempo di elaborazione sul server
Lo strumento da riga di comando ping accetta una pagina Web o un indirizzo IP e invia una richiesta tramite Internet Control Message Protocol (ICMP). ICMP non ha porte e non avrà quasi tempo sul server. Ciò significa che il tempo di ping, diviso per due, equivale all’incirca al tempo di latenza.
In questo esempio del comando ping, si può notare come la media di andata e ritorno sia di circa 134 millisecondi o circa 67 millisecondi per viaggio.
Nella realtà, invece, i tempi di risposta delle applicazioni in genere richiedono log dal server. Gli sviluppatori dovrebbero associare i log con il time-to-process per poi renderli disponibili attraverso un sistema di ricerca associato ai big data (Searchable Big Data System – SBDS), che va utilizzato per eseguire query relative a medie e statistiche legate alle prestazioni dell’applicazione.
Un altro modo per misurare i tempi di risposta in Google Chrome è di selezionare l’opzione Strumenti per Sviluppatori dal menu. Una volta selezionata la scheda Rete, va aggiornato il browser: in questo modo sarà possibile visualizzare un diagramma a cascata dei carichi di elementi immagine e pagina.
Questi strumenti misurano il tempo impiegato dalla richiesta per completare un round trip. Per calcolare il tempo di risposta si deve prendere il tempo totale e sottrarre la latenza. Per inciso, questo tipo di strumenti esistono anche per i dispositivi mobili.
Come aumentare le prestazioni applicative in 4 punti
Una volta capito il tempo di risposta, è possibile ottimizzare le prestazioni. Ecco 4 cose da considerare:
Granularizzare e analizzare
Il primo principio è semplice: si trova il servizio che causa il ritardo maggiore o che incide di più sulle prestazioni, si suddivide in diverse categorie come, ad esempio, on-line, server on-web e API. Una volta trovato il componente lento, lo si granularizza per analizzare quali sono le cause del ritardo e intervenire con le correzioni. Se è possibile, è consigliabile anche eseguire le varie richieste in parallelo. Se il problema è la latenza, non c’è molto da fare a livello DEV, dal momento che il problema è l’infrastruttura tra il client e il server web. La latenza, in questo caso, è nelle mani degli OPS.
Attenzione alle immagini
La maggior parte delle applicazioni Web include una grande quantità di file di contenuti statici che sono esattamente gli stessi, ogni volta principalmente sotto forma di pagine Web, JavaScript e immagini. Se si forniscono le immagini dal data center, un modo per migliorare la latenza è spostare il data center vicino ai punti di scambio Internet. Più realisticamente, una rete di distribuzione dei contenuti (Content Delivery Network – CDN) può posizionare i file in dozzine di luoghi su Internet per poi instradare le richieste al data center più vicino. Le operazioni potrebbero anche configurare i server Web in modo che includano tag entità nelle loro risposte, facendo così in modo che il browser possa memorizzare nella cache le immagini, invece di ricaricarle. Le immagini di complessità inferiore riducono le dimensioni dei file, mentre il codice minimizzato riduce le dimensioni dei file di testo. Su un gran numero di file, queste modifiche aumentano le prestazioni complessive dell’applicazione Web, anche se limitatamente.
Considerare il rendering incrementale
Alcuni progettisti di software si affidano al rendering incrementale, in cui gli elementi della pagina vengono caricati e visualizzati pezzo per pezzo per creare un’esperienza utente migliore anche quando i tempi di risposta complessivi non migliorano. Ad esempio, se si va sul sito di vendita al dettaglio di Amazon, si noterà come vengano visualizzate un mucchio di scatole: se i tasti funzioni visualizzato di recente o Consigliato per te non vengono visualizzati, il sito intanto riesce a mostrare tutto il resto della pagina. Proprio come gli sviluppatori eseguono lavori incrementali su progetti software, è possibile strutturare i siti Web allo stesso modo.
Non sottovalutare mai l’esperienza utente
A volte, le metriche non dicono tutta la verità che serve, quando serve. Gli esperti citano a proposito una metafora interessante: nessuno, infatti, decide di tagliarsi i capelli usando un righello. Allo stesso modo, il senso del tempo legato alle prestazioni di un’applicazione può essere molto soggettivo. Una persona, infatti, può percepire un ritardo nel caricamento di una pagina, che potrebbe significare un tempo superiore a 0,5 secondi. Il che non significa che sia necessariamente significativo o importante. Se il software è stato creato per un gruppo di assistenza clienti interno, i tempi di caricamento potrebbero non essere una priorità. Allo stesso modo, se il software è nuovo e innovativo, senza concorrenti reali, un ritardo fino a un secondo potrebbe essere un tempo di risposta accettabile (per ora). Una volta che il software ha concorrenti, i clienti potrebbero cambiare e scegliere quello più performante senza pensarci due volte… Il che significa non sottovalutare mai l’esperienza dell’utente rispetto al tempo di risposta.
