Risolvere i problemi di sovraccarico del server

Come determinare e correggere rapidamente un collo di bottiglia di un server, migliorare le prestazioni del server e prevenire le regressioni.

Katie Hempenius
Katie Hempenius
X

Panoramica

Questa guida illustra come risolvere il problema di un server sovraccarico in quattro passaggi:

  1. Valuta: determina il collo di bottiglia del server.
  2. Stabilizza: implementa correzioni rapide per mitigare l'impatto.
  3. Migliorare: aumenta e ottimizza le funzionalità del server.
  4. Monitoraggio: utilizza strumenti automatici per prevenire problemi futuri.

Valutazione

Quando il traffico sovraccarica un server, uno o più dei seguenti elementi possono diventare un collo di bottiglia: CPU, rete, memoria o I/O del disco. Identificare quale di questi è il collo di bottiglia consente di concentrare gli sforzi sulle mitigazioni più efficaci.

  • CPU: un utilizzo della CPU costantemente superiore all'80% deve essere esaminato e corretto. Le prestazioni del server spesso si deteriorano una volta che l'utilizzo della CPU raggiunge l'80-90% e diventa più pronunciato con l'avvicinarsi dell'utilizzo al 100%. L'utilizzo della CPU per gestire una singola richiesta è trascurabile, ma farlo nella scala che si incontra durante i picchi di traffico a volte può sovraccaricare un server. L'offload del servizio ad altre infrastrutture, la riduzione delle operazioni costose e la limitazione della quantità di richieste ridurranno l'utilizzo della CPU.
  • Rete: durante periodi di traffico elevato, la velocità effettiva di rete necessaria per soddisfare le richieste degli utenti può superare la capacità. Alcuni siti, a seconda del provider host, potrebbero raggiungere anche i limiti relativi al trasferimento cumulativo dei dati. La riduzione delle dimensioni e della quantità di dati trasferiti da e verso il server rimuoverà questo collo di bottiglia.
  • Memoria: quando un sistema non ha memoria sufficiente, i dati devono essere trasferiti su disco per l'archiviazione. L'accesso a un disco è notevolmente più lento rispetto alla memoria e questo può rallentare l'intera applicazione. Se la memoria è completamente esaurita, può verificarsi un errore di Memoria esaurita (OOM). La regolazione dell'allocazione della memoria, la correzione delle perdite di memoria e l'upgrade della memoria possono eliminare questo collo di bottiglia.
  • I/O disco: la velocità alla quale i dati possono essere letti o scritti dal disco è vincolata dal disco stesso. Se l'I/O del disco è un collo di bottiglia, aumentare la quantità di dati memorizzati nella cache può risolvere il problema (a fronte di un maggiore utilizzo della memoria). Se questa operazione non funziona, potrebbe essere necessario eseguire l'upgrade dei dischi.

Le tecniche descritte in questa guida sono incentrate sulla risoluzione dei colli di bottiglia della CPU e della rete. Per la maggior parte dei siti, CPU e rete saranno i colli di bottiglia più rilevanti durante un picco di traffico.

L'esecuzione di top sul server interessato è un buon punto di partenza per analizzare i colli di bottiglia. Se disponibile, puoi integrare questi dati con i dati storici del tuo provider host o con gli strumenti di monitoraggio.

Stabilizza

Un server sovraccarico può causare rapidamente errori a cascata in tutte le altre sezioni del sistema. È quindi importante stabilizzare il server prima di tentare di apportare modifiche più significative.

Limitazione di frequenza

La limitazione di frequenza protegge l'infrastruttura limitando il numero di richieste in entrata. Questo aspetto è sempre più importante man mano che le prestazioni del server si deteriorano: con l'aumento dei tempi di risposta, gli utenti tendono ad aggiornare la pagina in modo massiccio, aumentando ulteriormente il carico del server.

Correggi

Sebbene rifiutare una richiesta sia relativamente economico, il modo migliore per proteggere il server è gestire la limitazione della frequenza a monte, ad esempio tramite un bilanciatore del carico, un proxy inverso o una CDN.

Istruzioni:

Visita anche:

Memorizzazione nella cache HTTP

Cercare metodi per memorizzare i contenuti in modo più aggressivo. Se una risorsa può essere fornita da una cache HTTP (che si tratti della cache del browser o di una rete CDN), non è necessario richiederla al server di origine, riducendo così il carico del server.

Le intestazioni HTTP come Cache-Control, Expires e ETag indicano in che modo una risorsa deve essere memorizzata nella cache tramite HTTP. Il controllo e la correzione di queste intestazioni miglioreranno la memorizzazione nella cache.

Sebbene i service worker possano essere utilizzati per la memorizzazione nella cache, utilizzano una cache separata e sono un'integrazione, anziché una sostituzione, per una corretta memorizzazione nella cache HTTP. Per questo motivo, quando si gestisce un server sovraccarico, è opportuno concentrare gli sforzi sull'ottimizzazione della memorizzazione nella cache HTTP.

Diagnostica

Esegui Lighthouse e controlla il controllo Pubblica risorse statiche con un criterio di cache efficiente per visualizzare un elenco di risorse con una durata (TTL) breve-media. Per ogni risorsa elencata, valuta se il TTL deve essere aumentato. Come linea guida approssimativa:

  • Le risorse statiche devono essere memorizzate nella cache con un TTL lungo (1 anno).
  • Le risorse dinamiche devono essere memorizzate nella cache con un breve TTL (3 ore).

Correggi

Imposta l'istruzione max-age dell'intestazione Cache-Control sul numero di secondi appropriato.

Istruzioni:

Degrado controllato

Il degrado graduale è la strategia di ridurre temporaneamente la funzionalità in modo da eliminare il carico in eccesso da un sistema. Questo concetto può essere applicato in molti modi diversi: ad esempio, pubblicando una pagina di testo statica invece di un'applicazione completa, disattivando la ricerca o restituendo meno risultati di ricerca oppure disattivando alcune funzionalità costose o non essenziali. Occorre porre l'attenzione sulla rimozione di funzionalità che possono essere rimosse facilmente e in sicurezza con un impatto minimo sull'attività.

Migliora

Utilizza una rete CDN (Content Delivery Network)

La pubblicazione di asset statici può essere trasferita dal tuo server a una rete CDN (Content Delivery Network), riducendo così il carico.

La funzione principale di una rete CDN è fornire contenuti agli utenti in modo rapido, mettendo a disposizione un'ampia rete di server che si trovano vicino agli utenti. Tuttavia, la maggior parte delle CDN offre anche funzionalità aggiuntive relative alle prestazioni come compressione, bilanciamento del carico e ottimizzazione dei contenuti multimediali.

Configurare una rete CDN

Le reti CDN traggono vantaggio dalla scalabilità, quindi l'utilizzo della tua CDN personale raramente ha senso. Una configurazione CDN di base è abbastanza rapida da impostare (circa 30 minuti) e consiste nell'aggiornamento dei record DNS in modo che puntino alla rete CDN.

Ottimizza l'utilizzo di CDN

Diagnostica

Identifica le risorse che non vengono gestite da una rete CDN (ma che dovrebbero esserlo) eseguendo WebPageTest. Nella pagina dei risultati, fai clic sul quadrato sopra "Utilizzo effettivo di CDN" per visualizzare l'elenco delle risorse da pubblicare da una rete CDN.

Freccia che punta al pulsante "Utilizzo efficace di CDN"
Risultati di WebPageTest

Correggi

Se una risorsa non viene memorizzata nella cache dal CDN, verifica che siano soddisfatte le seguenti condizioni:

Applica la scalabilità delle risorse di computing

La decisione di scalare le risorse di computing deve essere presa con attenzione. Sebbene spesso sia necessario scalare le risorse di calcolo, farlo prematuramente può generare complessità dell'architettura e costi finanziari non necessari.

Diagnostica

Un valore elevato di Time To First Byte (TTFB) può indicare che un server sta per raggiungere la sua capacità. Puoi trovare queste informazioni nel controllo di Lighthouse Ridurre i tempi di risposta del server (TTFB).

Per indagare ulteriormente, usa uno strumento di monitoraggio per valutare l'utilizzo della CPU. Se l'utilizzo attuale o previsto della CPU supera l'80%, ti consigliamo di aumentare i server.

Correggi

L'aggiunta di un bilanciatore del carico consente di distribuire il traffico tra più server. Un bilanciatore del carico si trova davanti a un pool di server e instrada il traffico al server appropriato. I cloud provider offrono i propri bilanciatori del carico (GCP, AWS, Azure) oppure è possibile configurarli autonomamente utilizzando HAProxy o NGINX. Una volta attivato un bilanciatore del carico, è possibile aggiungere altri server.

Oltre al bilanciamento del carico, la maggior parte dei cloud provider offre la scalabilità automatica (GCP, AWS, Azure). La scalabilità automatica funziona insieme al bilanciamento del carico: la scalabilità automatica consente di fare automaticamente lo scale up e lo scale down delle risorse di calcolo in base alla domanda in un dato momento. Detto questo, la scalabilità automatica non è magica: ci vuole tempo prima che le nuove istanze siano online e richiede una configurazione significativa. A causa dell'ulteriore complessità che la scalabilità automatica comporta, prima dovrebbe essere considerata una configurazione più semplice basata su un bilanciatore del carico.

Abilita la compressione

Le risorse basate su testo devono essere compresse utilizzando gzip o brotli. Gzip può ridurre le dimensioni del trasferimento di queste risorse di circa il 70%.

Diagnostica

Utilizza il controllo Lighthouse Abilita la compressione del testo per identificare le risorse che devono essere compresse.

Correggi

Attiva la compressione aggiornando la configurazione del server. Istruzioni:

Ottimizza immagini e contenuti multimediali

Le immagini costituiscono la maggior parte delle dimensioni dei file della maggior parte dei siti web; l'ottimizzazione delle immagini può ridurre rapidamente e notevolmente le dimensioni di un sito.

Diagnostica

Lighthouse ha una serie di controlli che segnalano potenziali ottimizzazioni delle immagini. In alternativa, un'altra strategia è quella di utilizzare DevTools per identificare i file immagine più grandi: queste immagini saranno probabilmente buone candidati per l'ottimizzazione.

Controlli di Lighthouse pertinenti:

Flusso di lavoro di Chrome DevTools:

Correggi

Se hai poco tempo...

Concentrati sull'identificazione di immagini grandi e caricate di frequente e ottimizzale manualmente con uno strumento come Squoosh. Le immagini hero sono spesso ottimi candidati per l'ottimizzazione.

Aspetti da tenere presenti:

  • Dimensioni: le immagini non devono essere più grandi del necessario.
  • Compressione: in generale, un livello di qualità pari a 80-85 ha un effetto minimo sulla qualità dell'immagine e una riduzione delle dimensioni dei file del 30-40%.
  • Formato: utilizza JPEG per le foto anziché PNG; usa MP4 per contenuti animati anziché GIF.

Se hai più tempo...

Valuta la possibilità di configurare una CDN immagine se le immagini costituiscono una parte considerevole del tuo sito. Le CDN di immagine sono progettate per la pubblicazione e l'ottimizzazione delle immagini e scaricheranno la pubblicazione delle immagini dal server di origine. La configurazione di una rete CDN immagine è semplice, ma richiede l'aggiornamento degli URL immagine esistenti in modo che puntino alla rete CDN immagine.

Visita anche:

Minimizza JS e CSS

La minimizzazione rimuove i caratteri non necessari da JavaScript e CSS.

Diagnostica

Utilizza i controlli Lighthouse Minimizza CSS e Minimizza JavaScript per identificare le risorse che necessitano di minimizzazione.

Correggi

Se hai poco tempo, concentrati sulla minimizzazione del tuo JavaScript. La maggior parte dei siti ha più JavaScript che CSS, quindi questo avrà un impatto maggiore.

Monitora

Gli strumenti di monitoraggio del server forniscono la raccolta dei dati, dashboard e avvisi relativi alle prestazioni del server. Il loro utilizzo può aiutare a prevenire e mitigare futuri problemi di prestazioni del server.

La configurazione del monitoraggio deve essere mantenuta il più semplice possibile. La raccolta e l'invio di avvisi eccessivi hanno i suoi costi: maggiore è l'ambito o la frequenza della raccolta dei dati, più costoso è la raccolta e l'archiviazione; un numero eccessivo di avvisi porta inevitabilmente a ignorare le pagine.

Gli avvisi dovrebbero utilizzare metriche che rilevano i problemi in modo coerente e preciso. Il tempo di risposta del server (latenza) è una metrica particolarmente adatta a questo scopo: rileva un'ampia varietà di problemi ed è correlata direttamente all'esperienza utente. Gli avvisi basati su metriche di livello inferiore come l'utilizzo della CPU possono essere un complemento utile, ma individuano un sottoinsieme più ridotto di problemi. Inoltre, gli avvisi dovrebbero basarsi sulle prestazioni osservate alla coda (ovvero il 95° o 99° percentile), piuttosto che sulle medie. In caso contrario, le medie possono oscurare facilmente i problemi che non interessano tutti gli utenti.

Correggi

Tutti i principali cloud provider offrono i propri strumenti di monitoraggio (GCP, AWS, Azure). Inoltre, Netdata è un'eccellente alternativa senza costi e open source. Indipendentemente dallo strumento scelto, dovrai installare l'agente di monitoraggio dello strumento su ogni server che vuoi monitorare. Al termine, assicurati di configurare gli avvisi.

Istruzioni: