Sito lento, server scarico: scoprire dove finisce il tempo

Perché il database è il solito sospetto

Quando una pagina rallenta, il database è dove il sintomo diventa visibile per primo. Le connessioni si accumulano, la process list si riempie di query nello stato sending data, e lo slow query log comincia a crescere. Tutto questo è reale, e nulla di tutto questo dice dove sia finito il tempo. Il database sta alla fine della maggior parte dei percorsi di richiesta. Una pagina che lo chiama duecento volte invece di due, un worker che tiene aperta una connessione mentre aspetta un gateway di pagamento, una cache che viene aggirata a ogni hit: ciascuno di questi casi si manifesta come carico sul database, perché il database sta facendo esattamente ciò che gli viene chiesto, più spesso di quanto dovrebbe essergli chiesto.

Lo stesso vale per il server. Una macchina con un carico alto è una macchina a cui viene dato del lavoro. Se quel lavoro sia necessario è una domanda a cui il grafico del carico non può rispondere.

Tracciate una richiesta, non l'intero sito

Il metodo è scegliere una URL lenta e seguirla attraverso i livelli, misurando a ogni confine. Partite dall'esterno, da una macchina che non sta sulla stessa rete, e lasciate che curl riporti dove finisce il tempo prima che arrivi il primo byte.

$ curl -o /dev/null -s -w 'dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n' https://www.example.com/slow-page

Se il tempo al primo byte è la maggior parte del totale, l'attesa sta sul lato server. Se il totale è molto più grande del tempo al primo byte, la pagina è pesante oppure la storia è il percorso tra il visitatore e l'edge, e il server non faceva parte dell'attesa.

Sulla macchina, campionate la CPU mentre la richiesta lenta è in corso, non un'ora di quiete più tardi.

$ mpstat -P ALL 1 5
$ vmstat 1 5

Un server per lo più scarico durante una richiesta lenta, senza iowait e senza steal, si è scagionato da solo. Il tempo viene speso aspettando qualcosa, non calcolando.

Poi l'applicazione. La maggior parte dei framework può registrare, per richiesta, il numero di query emesse, il tempo totale speso in esse e il tempo speso in chiamate HTTP in uscita. Attivatelo per la URL lenta. Due numeri chiudono la discussione: quante query emette una singola pagina, e quanto del tempo totale è stato speso completamente fuori dall'applicazione.

Infine il database, con lo slow query log attivo e la soglia abbastanza bassa da catturare ciò che conta.

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 0.2;
SET GLOBAL log_queries_not_using_indexes = ON;

Leggete il log nella finestra della richiesta lenta. Una manciata di query che impiegano secondi ciascuna è un problema di database. Migliaia di query che impiegano un millisecondo ciascuna è un problema dell'applicazione di cui il database viene incolpato.

Gli schemi che emergono dalle misure

Con i livelli separati, la causa tende a prendere una di poche forme.

Un endpoint chiamato in un ciclo. Un front end che richiede di nuovo la stessa risorsa a ogni cambio di stato, o una pagina che emette una query per riga invece di una query per pagina. Il database risponde a ogni chiamata in fretta; il problema è il numero.

Una chiamata sincrona a qualcun altro. Un fornitore di pagamenti, un ERP, un'API di spedizione, un tag manager, seduti sul percorso della richiesta dietro un timeout lungo. Il server è scarico per tutta l'attesa, e la pagina è lenta quanto la terza parte più lenta da cui dipende.

Una cache che viene vanificata. Header che vietano la cache su pagine che non cambiano, oppure nessuna cache all'edge davanti a traffico anonimo che non è mai stato dinamico.

Pool dimensionati a occhio. Pool di worker, di connessioni e di buffer impostati troppo grandi tanto spesso quanto troppo piccoli. Un pool molto più grande di ciò che la macchina può servire in parallelo trasforma una coda in un thrashing.

L'esaurimento reale è l'ultima forma, e quando compare è di solito a valle di una delle prime tre. La macchina che finisce qualcosa è la fine della storia, non l'inizio.

Cosa cambia un server più grande

Aggiungere core o memoria accorcia la parte della richiesta che stava calcolando. Se quella parte era già piccola, la pagina non diventa più veloce; l'attesa si sposta con essa. Il ciclo continua a ciclare, la terza parte continua a prendersi il suo tempo, la cache è ancora aggirata. L'upgrade nasconde inoltre la misura che avrebbe trovato la causa, perché il grafico che era rosso ora è ambra, e il ticket si chiude.

Per questo tracciamo prima di fare un preventivo. Una piattaforma sana resta noiosa, e il lavoro è trovare il livello a cui appartiene il tempo, anche quando quel livello sta sopra qualsiasi cosa gestiamo noi, e restituire la misura che indica la riga.