Come controllare il tempo di risposta del server

Tempo di risposta, TTFB e caricamento pagina non sono lo stesso numero

Vengono usati in modo intercambiabile e rispondono a domande diverse:

• Il tempo di connessione è la risoluzione DNS più l'handshake TCP più l'handshake TLS. È principalmente distanza e qualità della rete, e il codice del server non c'entra nulla.
• Il time to first byte (TTFB) è il momento in cui arriva il primo byte della risposta, misurato dall'inizio della richiesta. Include il tempo di connessione più l'elaborazione del server: routing, query al database, rendering dei template, eventuali chiamate a API upstream.
• Il tempo di elaborazione del server è il TTFB meno il tempo di connessione. È la parte che puoi correggere nella tua applicazione.
• Il tempo di caricamento della pagina è tutto: l'HTML, poi ogni immagine, foglio di stile, script e font che il browser recupera, più il lavoro di renderizzarli. Una pagina può avere un TTFB eccellente e comunque impiegare otto secondi a caricarsi.

Confonderli porta a ottimizzare la cosa sbagliata. Comprimere le immagini non fa nulla per una query al database lenta, e un database più veloce non fa nulla per una pagina che porta con sé quattro megabyte di JavaScript.

Misurarlo con curl

curl riporta ogni fase separatamente, il che ti permette di separare il costo della connessione da quello del server in un solo comando:

curl -o /dev/null -sS -w   "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n"   https://example.com/

Tutti i valori sono in secondi dall'inizio della richiesta, quindi ognuno include quelli precedenti. L'elaborazione del server è ttfb meno tls, o meno connect su HTTP semplice. Eseguilo tre o quattro volte: la prima richiesta può pagare il prezzo di una cache fredda o di una connessione nuova, e un solo campione non è una misurazione.

Due cose da tenere ben distinte. Questo misura solo il documento HTML, non la pagina, quindi sembrerà sempre più veloce di un test da browser. E una pagina non in cache, per utente autenticato o di ricerca è spesso molto più lenta della homepage, quindi misura l'URL che ti interessa e non /.

Cosa conta come normale

Non esiste una soglia universale. Queste fasce sono una guida di lavoro ragionevole per una richiesta di documento misurata da una postazione vicina ai tuoi visitatori:

• Sotto i 200 ms. Veloce. Tipico di contenuti statici, una cache calda, o un edge CDN che risponde direttamente.
• Da 200 a 500 ms. Normale per una pagina dinamica che interroga un database. Nessuno se ne accorge.
• Da 500 ms a 1 s. Percepibile. Di solito una query che ha bisogno di un indice, un template non in cache, o una chiamata upstream lenta.
• Da 1 a 3 s. Gli utenti lo percepiscono, e i motori di ricerca lo misurano. Vale la pena trattarlo come un difetto.
• Oltre 3 s. Qualcosa non va: un server saturo, un lock, un servizio upstream che va in timeout, o una richiesta che fa molto più lavoro del necessario.

Il confronto di gran lunga più utile è con te stesso. Una pagina che rispondeva in 300 ms il mese scorso e oggi risponde in 900 ms ha una causa specifica introdotta nel mezzo, e saperlo vale più di qualsiasi benchmark pubblicato.

Perché varia in base alla postazione

La distanza costa tempo e non si può eliminare con l'ottimizzazione. Ogni round trip tra client e server richiede almeno quanto consente il percorso fisico, e una connessione TLS ha bisogno di diversi round trip prima ancora che possa iniziare il primo byte della risposta. Ecco perché lo stesso server può rispondere in 150 ms localmente e in 700 ms da un altro continente pur facendo esattamente lo stesso lavoro.

Anche l'instradamento conta, ed è meno prevedibile della distanza: il traffico tra due reti può prendere un percorso scadente che aggiunge latenza per una regione e per nessun'altra. Se usi una CDN, alcune postazioni vengono servite da una copia in cache vicina mentre altre mancano la cache e pagano l'intero viaggio fino all'origine, il che produce una dispersione ampia tra le postazioni per lo stesso URL.

Quindi misura da dove si trovano i tuoi utenti, non da dove si trova il tuo server, e confronta situazioni simili tra loro. Un numero senza una postazione associata non è confrontabile con niente.

Quando la lentezza significa che qualcosa è rotto

Alcune lentezze sono un avvertimento più che un problema di prestazioni:

• Un tempo di risposta che cresce costantemente sotto carico significa che il server è saturo. Finisce in timeout, non solo in pagine lente.
• Tempi raggruppati esattamente a 30 o 60 secondi sono timeout, non lentezza. Qualcosa a monte non sta rispondendo e un proxy attende di esaurire il proprio limite prima di arrendersi con un 504.
• Veloce la maggior parte del tempo con picchi enormi occasionali di solito indica un lock, un job cron, un backup, oppure una cache che scade e ogni richiesta la ricostruisce tutta insieme.
• Lento solo per gli utenti autenticati significa che la cache sta gestendo il traffico anonimo e nasconde sotto un'applicazione genuinamente lenta.
• Lento solo da una regione è un problema di rete o di CDN, non un problema applicativo, e nessuna quantità di lavoro sul backend lo risolverà.

Accorgersi del giorno in cui è cambiato

Una singola misurazione ti dice cosa è successo per una richiesta, da un posto, in un momento, e il tempo di risposta è esattamente il tipo di metrica che va alla deriva invece di rompersi di colpo. I controlli pianificati misurano lo stesso URL dalle stesse postazioni in modo continuo, mantengono lo storico così puoi individuare il giorno in cui è cambiato, e avvisano quando il tempo supera una soglia invece che quando un cliente si lamenta. HostTracker esegue questi controlli da oltre 300 postazioni in 158 città, così un rallentamento regionale è visibile come tale. Esegui subito un controllo con lo strumento di controllo HTTP. Quando il server è veloce e la pagina non lo è ancora, il resto della risposta è in come controllare la velocità di un sito web.