Risolvere i problemi di sovraccarico del server

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

Katie Hempenius
Katie Hempenius
X

Panoramica

Questa guida mostra come risolvere il problema di un server sovraccarico in 4 passaggi:

  1. Valutazione: determina il collo di bottiglia del server.
  2. Stabilizzazione: implementa correzioni rapide per mitigare l'impatto.
  3. Miglioramento: potenzia e ottimizza le funzionalità del server.
  4. Monitoraggio: utilizza strumenti automatizzati per evitare problemi futuri.

Valuta

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 di maggiore impatto.

  • CPU: un utilizzo della CPU costantemente superiore all'80% deve essere esaminato e corretto. Le prestazioni del server spesso peggiorano quando l'utilizzo della CPU raggiunge l'80-90% circa e diventano più evidenti quando l'utilizzo si avvicina al 100%. L'utilizzo della CPU per la gestione di una singola richiesta è trascurabile, ma farlo su larga scala durante i picchi di traffico può a volte sovraccaricare un server. L'offload della gestione su un'altra infrastruttura, la riduzione delle operazioni costose e la limitazione della quantità di richieste ridurranno l'utilizzo della CPU.
  • Rete: durante i periodi di traffico elevato, la velocità effettiva della rete richiesta per soddisfare le richieste degli utenti può superare la capacità. Alcuni siti, a seconda del provider host, potrebbero anche raggiungere i limiti relativi al trasferimento di dati cumulativo. La riduzione delle dimensioni e della quantità di dati trasferiti da e verso il server eliminerà questo collo di bottiglia.
  • Memoria: quando un sistema non dispone di memoria sufficiente, i dati devono essere trasferiti sul disco per l'archiviazione. L'accesso al disco è notevolmente più lento rispetto alla memoria e questo può rallentare un'intera applicazione. Se la memoria si esaurisce completamente, possono verificarsi errori di out of memory (OOM). La regolazione dell'allocazione della memoria, la correzione delle perdite di memoria e l'upgrade della memoria possono rimuovere questo collo di bottiglia.
  • I/O del disco: la velocità con cui i dati possono essere letti o scritti dal disco è limitata dal disco stesso. Se l'I/O del disco è un collo di bottiglia, l'aumento della quantità di dati memorizzati nella cache può alleviare questo problema (a scapito di un maggiore utilizzo della memoria). Se il problema persiste, potrebbe essere necessario eseguire l'upgrade dei dischi.

Le tecniche descritte in questa guida si concentrano sulla risoluzione dei colli di bottiglia della CPU e della rete. Per la maggior parte dei siti, la CPU e la 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 l'analisi dei colli di bottiglia. Se disponibili, integra queste informazioni con i dati storici del tuo provider host o degli strumenti di monitoraggio.

Stabilizza

Un server sovraccarico può portare rapidamente a errori a cascata in altre parti del sistema. Pertanto, è 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 è sempre più importante man mano che le prestazioni del server peggiorano: con l'aumentare dei tempi di risposta, gli utenti tendono ad aggiornare la pagina in modo aggressivo, aumentando ulteriormente il carico del server.

Correggi

Sebbene il rifiuto di una richiesta sia un'operazione relativamente poco costosa, il modo migliore per proteggere il server è gestire la limitazione di frequenza in un punto a monte, ad esempio tramite un bilanciatore del carico, un reverse proxy o una CDN.

Istruzioni:

Visita anche:

Memorizzazione nella cache HTTP

Cerca modi per memorizzare i contenuti nella cache in modo più aggressivo. Se una risorsa può essere pubblicata da una cache HTTP (che si tratti della cache del browser o di una CDN), non è necessario richiederla al server di origine, il che riduce il carico del server.

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

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

Diagnostica

Esegui Lighthouse e osserva il controllo Pubblica asset statici con una policy della cache efficace per visualizzare un elenco di risorse con una durata (TTL) da breve a 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 TTL breve (3 ore).

Correggi

Imposta la direttiva max-age dell'intestazione Cache-Control sul numero di secondi appropriato.

Istruzioni:

Riduzione controllata

La riduzione controllata è la strategia di riduzione temporanea della funzionalità per eliminare il carico in eccesso da un sistema. Questo concetto può essere applicato in molti modi diversi: ad esempio, pubblicando una pagina di testo statico anziché un'applicazione completa, disattivando la ricerca o restituendo meno risultati di ricerca oppure disattivando alcune funzionalità costose o non essenziali. L'accento deve essere posto sulla rimozione delle funzionalità che possono essere rimosse in modo sicuro e semplice 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 CDN è fornire rapidamente contenuti agli utenti attraverso un'ampia rete di server situati vicino agli utenti. Tuttavia, la maggior parte delle CDN offre anche funzionalità aggiuntive relative alle prestazioni, come la compressione, il bilanciamento del carico e l'ottimizzazione dei contenuti multimediali.

Configura una CDN

Le CDN traggono vantaggio dalla scalabilità, quindi raramente ha senso gestire una propria CDN. Una configurazione CDN di base è abbastanza rapida da configurare (~30 minuti) e consiste nell'aggiornare i record DNS in modo che puntino alla CDN.

Ottimizza l'utilizzo della CDN

Diagnostica

Identifica le risorse che non vengono pubblicate da una CDN (ma dovrebbero esserlo) eseguendo WebPageTest. Nella pagina dei risultati, fai clic sul quadrato sopra "Utilizzo efficace della CDN" per visualizzare l'elenco delle risorse che devono essere pubblicate da una CDN.

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

Correggi

Se una risorsa non viene memorizzata nella cache dalla 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 sia spesso necessario scalare le risorse di calcolo, farlo prematuramente può generare complessità architetturale 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à massima. Puoi trovare queste informazioni nel controllo Riduci i tempi di risposta del server (TTFB) di Lighthouse.

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

Correggi

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

Oltre al bilanciamento del carico, la maggior parte dei provider cloud offre la scalabilità automatica (GCP, AWS, Azure). La scalabilità automatica funziona in combinazione con il bilanciamento del carico: la scalabilità automatica aumenta e riduce automaticamente le risorse di computing in base alla domanda in un determinato momento. Detto questo, la scalabilità automatica non è magica: l'attivazione di nuove istanze richiede tempo e una configurazione significativa. A causa della complessità aggiuntiva che comporta la scalabilità automatica, è necessario considerare prima una configurazione più semplice basata sul bilanciatore del carico.

Abilita la compressione

Le risorse basate sul 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 Attiva la compressione del testo di Lighthouse 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 in modo significativo le dimensioni di un sito.

Diagnostica

Lighthouse offre una serie di controlli che segnalano potenziali ottimizzazioni delle immagini. In alternativa, un'altra strategia consiste nell'utilizzare DevTools per identificare i file immagine più grandi, che probabilmente saranno buoni candidati per l'ottimizzazione.

Controlli Lighthouse pertinenti:

Flusso di lavoro di Chrome DevTools:

Correggi

Se hai poco tempo…

Concentrati sull'identificazione delle immagini di grandi dimensioni e caricate di frequente e ottimizzale manualmente con uno strumento come Squoosh. Le immagini hero sono spesso buoni 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à di 80-85 avrà un effetto minimo sulla qualità dell'immagine, riducendo al contempo le dimensioni del file del 30-40%.
  • Formato: utilizza i file JPEG per le foto anziché i file PNG; utilizza i file MP4 per i contenuti animati anziché i file GIF.

Se hai più tempo…

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

Visita anche:

Minimizza JS e CSS

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

Diagnostica

Utilizza i controlli di Lighthouse Minimizza CSS e Minimizza JavaScript per identificare le risorse che devono essere minimizzate.

Correggi

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

Monitoraggio

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

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

Gli avvisi devono utilizzare metriche che rilevino i problemi in modo coerente e accurato. Il tempo di risposta del server (latenza) è una metrica particolarmente adatta a questo scopo: rileva un'ampia gamma di problemi ed è direttamente correlata all'esperienza utente. Gli avvisi basati su metriche di livello inferiore, come l'utilizzo della CPU, possono essere un utile supplemento, ma rilevano un sottoinsieme più piccolo di problemi. Inoltre, gli avvisi devono essere basati sulle prestazioni osservate nella coda (in altre parole, il 95° o il 99° percentile), anziché sulle medie. In caso contrario, le medie possono facilmente nascondere 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 open source senza costi. 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: