Come prepariamo un sito di notizie a un picco di traffico.
Il mestiere di un sito di notizie sono i picchi. Ecco il metodo con cui ne prepariamo uno: leggere i log giusti, sapere dov'è il tetto, controllare ogni livello prima di spendere e fare i conti.
In questo articolo 4 sezioni
- Il traffico espone i tetti; è la configurazione a impostarli. Prepararsi a un picco significa trovarli prima che li trovi il pubblico.
- Per prima cosa, confermate quale log porta davvero il traffico del sito. Il log di default del server può contenere una piccola quota mentre il log del vhost del sito contiene il resto.
- Controllate ogni livello prima di spendere. Spesso il database è veloce e inattivo mentre il lavoro si accoda un livello più su.
- Poi l'aritmetica: worker diviso secondi per richiesta è il vostro vero tetto in richieste al secondo. Dimensionate il pool al picco che raggiungerete davvero, più un margine.
Il mestiere di un sito di notizie sono i picchi: quando la notizia esplode, il pubblico arriva tutto insieme. Prepararsi a quel momento è raramente una questione di hardware. È una questione di configurazione: il numero di worker, i timeout, i log, la cache. Ecco come ne prepariamo uno.
Prima leggete il log giusto
La prima disciplina è contare correttamente. Su un web server tipico il log di default e il log del vhost del sito sono file diversi, e quello di default può contenere solo una piccola quota del traffico. Dimensionate qualcosa dal log sbagliato e lo dimensionerete per il carico sbagliato.
Sapete dov'è il tetto
Sotto carico, i tempi di risposta vi dicono dov'è il limite. La lentezza organica si disperde: alcune richieste un po' lente, alcune molto lente. Richieste lente che si raggruppano esattamente al timeout del gateway significano che il livello dietro il gateway sta esaurendo i worker entro il suo budget. È una firma di saturazione, e punta dritto all'impostazione da dimensionare.
Controllate ogni livello prima di spendere
Prima che qualcuno compri RAM o aggiorni il livello dati, controllatelo. Un database veloce e inattivo, senza query lente, che risponde a tutto nel momento in cui gli viene chiesto, non è il livello da dimensionare. Il livello da dimensionare è quello con tutti i worker occupati. Quel pattern ha il suo post in ridimensionare verso il basso, non verso l'alto.
Il vostro tetto è aritmetica
WORKER
SEC / RICHIESTA
RICH / SEC
La preparazione è dimensionamento, non shopping: il pool di worker calcolato dal picco che un sito di notizie raggiungerà davvero, più un margine, entro un budget di memoria per worker misurato. Poi un livello di cache che serve contenuto stale quando il backend rallenta, così un backend occupato degrada a pagine un po' vecchie invece che a pagine di errore. La piattaforma assorbe il picco.
“Il traffico trova il tetto che impostate voi. Impostatelo di proposito.”
Risposte dirette
Perché un sito restituisce errori 502 sotto traffico intenso?+
Di solito il livello dietro il gateway ha esaurito i worker e il gateway si arrende al suo timeout. La firma sono richieste lente inchiodate esattamente a un numero. Contate prima gli errori sul log del vhost corretto, perché il log di default può contenere solo una frazione del vostro traffico.
Quanti worker dovrebbe avere il mio application server?+
Calcolatelo: worker diviso secondi medi per richiesta è il vostro tetto in richieste al secondo. Dimensionate per il picco che raggiungerete davvero più un margine, entro un budget di memoria per worker misurato, invece di fidarvi del default del pacchetto.
Il database è il collo di bottiglia quando il traffico sale?+
Verificate prima di spendere. Controllate se è inattivo o occupato e se esistono query lente. Spesso il database è veloce e inattivo e il lavoro si accoda un livello più su. Controllate prima ogni livello.
Come preparo un sito a un picco di traffico?+
Fate il calcolo dei worker sul vostro picco realistico, confermate quali log portano davvero il vostro traffico, fate un load test fino al tetto calcolato e mettete davanti una cache stale-on-error, così un backend lento serve pagine vecchie invece di errori.
Più traffico non richiede semplicemente più server?+
Prima o poi, ma quasi mai per primo. Prima usate la capacità che la vostra configurazione sta trattenendo: pool dimensionati correttamente, timeout sensati, una cache che assorbe la tempesta di letture. L'hardware comprato per coprire un'impostazione di configurazione è la modifica di configurazione più costosa che esista.
Vi aspettate presto il vostro giorno migliore?
Lancio, stampa, picco di stagione: portateci la data. Faremo il calcolo dei worker, leggeremo i log giusti e faremo del picco solo un altro grafico.
Parla con un ingegnereSiete arrivati alla fine.
Mettete la lettura al lavoro
Cosa fate girare?
Raccontateci il carico di lavoro, il traffico e i requisiti di ripristino. Partite dal configuratore di server, oppure discutete i dettagli con un ingegnere.
Scritto dagli ingegneri che costruiscono e gestiscono l'infrastruttura che descrive.Parla con un ingegnere