Résoudre un problème de serveur surchargé

Découvrez comment identifier et résorber rapidement un goulot d'étranglement, améliorer les performances du serveur et empêcher les régressions.

Katie Hempenius
Katie Hempenius
X

Présentation

Ce guide vous explique comment résoudre les problèmes d'un serveur surchargé en quatre étapes :

  1. Évaluation : déterminez le goulot d'étranglement du serveur.
  2. Stabiliser : implémentez des correctifs rapides pour limiter l'impact.
  3. Améliorer : augmenter et optimiser les capacités du serveur.
  4. Surveiller : utilisez des outils automatisés pour éviter les problèmes à l'avenir.

Évaluer

Lorsque le trafic surcharge un serveur, un ou plusieurs des éléments suivants peuvent devenir un goulot d'étranglement : le processeur, le réseau, la mémoire ou les E/S du disque. Identifier lequel de ces éléments constitue le goulot d'étranglement permet de concentrer les efforts sur les mesures d'atténuation les plus efficaces.

  • Processeur : une utilisation du processeur constamment supérieure à 80 % doit être examinée et corrigée. Les performances du serveur se dégradent souvent lorsque l'utilisation du processeur atteint environ 80 à 90 %, et cette dégradation s'accentue à mesure que l'utilisation se rapproche de 100 %. L'utilisation du processeur pour diffuser une seule requête est négligeable, mais le faire à l'échelle rencontrée lors des pics de trafic peut parfois surcharger un serveur. Pour réduire l'utilisation du processeur, vous pouvez décharger la diffusion vers une autre infrastructure, réduire les opérations coûteuses et limiter le nombre de requêtes.
  • Réseau : pendant les périodes de trafic élevé, le débit réseau requis pour répondre aux requêtes des utilisateurs peut dépasser la capacité. Selon le fournisseur d'hébergement, certains sites peuvent également atteindre des limites concernant le transfert cumulé de données. Pour éliminer ce goulot d'étranglement, réduisez la taille et la quantité des données transférées vers et depuis le serveur.
  • Mémoire : lorsqu'un système ne dispose pas de suffisamment de mémoire, les données doivent être déchargées sur le disque pour être stockées. L'accès au disque est considérablement plus lent que l'accès à la mémoire, ce qui peut ralentir l'ensemble d'une application. Si la mémoire est complètement épuisée, cela peut entraîner des erreurs de mémoire insuffisante (OOM). Pour éliminer ce goulot d'étranglement, vous pouvez ajuster l'allocation de mémoire, corriger les fuites de mémoire et augmenter la mémoire.
  • E/S du disque : la vitesse à laquelle les données peuvent être lues ou écrites sur le disque est limitée par le disque lui-même. Si les E/S du disque constituent un goulot d'étranglement, augmenter la quantité de données mises en cache en mémoire peut atténuer ce problème (au détriment d'une utilisation accrue de la mémoire). Si cela ne fonctionne pas, vous devrez peut-être mettre à niveau vos disques.

Les techniques présentées dans ce guide se concentrent sur la résolution des goulots d'étranglement au niveau du processeur et du réseau. Pour la plupart des sites, le processeur et le réseau sont les goulots d'étranglement les plus pertinents lors d'un pic de trafic.

L'exécution de top sur le serveur concerné est un bon point de départ pour identifier les goulots d'étranglement. Si possible, complétez ces informations avec les données historiques de votre fournisseur d'hébergement ou de vos outils de surveillance.

Stabiliser

Un serveur surchargé peut rapidement entraîner des défaillances en cascade ailleurs dans le système. Il est donc important de stabiliser le serveur avant d'essayer d'apporter des modifications plus importantes.

Limitation du débit

La limitation du débit protège l'infrastructure en limitant le nombre de requêtes entrantes. Cela est d'autant plus important que les performances du serveur se dégradent : à mesure que les temps de réponse augmentent, les utilisateurs ont tendance à actualiser la page de manière agressive, ce qui augmente encore la charge du serveur.

Solution

Bien que le rejet d'une requête soit relativement peu coûteux, la meilleure façon de protéger votre serveur est de gérer la limitation du débit en amont, par exemple via un équilibreur de charge, un proxy inverse ou un CDN.

Instructions :

Autres références :

Mise en cache HTTP

Recherchez des moyens de mettre en cache le contenu de manière plus agressive. Si une ressource peut être diffusée à partir d'un cache HTTP (qu'il s'agisse du cache du navigateur ou d'un CDN), elle n'a pas besoin d'être demandée au serveur d'origine, ce qui réduit la charge du serveur.

Les en-têtes HTTP tels que Cache-Control, Expires et ETag indiquent comment une ressource doit être mise en cache par un cache HTTP. L'audit et la correction de ces en-têtes amélioreront la mise en cache.

Bien que les service workers puissent également être utilisés pour la mise en cache, ils utilisent un cache distinct et complètent la mise en cache HTTP appropriée, plutôt que de la remplacer. C'est pourquoi, lorsque vous gérez un serveur surchargé, vous devez vous concentrer sur l'optimisation de la mise en cache HTTP.

Diagnostic

Exécutez Lighthouse et consultez l'audit Diffuser des éléments statiques grâce à des règles de cache efficaces pour afficher la liste des ressources dont la durée de vie (TTL) est courte ou moyenne. Pour chaque ressource listée, déterminez si la valeur TTL doit être augmentée. À titre indicatif :

  • Les ressources statiques doivent être mises en cache avec une valeur TTL longue (un an).
  • Les ressources dynamiques doivent être mises en cache avec une valeur TTL courte (trois heures).

Solution

Définissez l'instruction max-age de l'en-tête Cache-Control sur le nombre de secondes approprié.

Instructions :

Dégradation élégante

La dégradation élégante est une stratégie qui consiste à réduire temporairement les fonctionnalités afin de décharger un système d'une charge excessive. Ce concept peut être appliqué de différentes manières : par exemple, en diffusant une page de texte statique au lieu d'une application complète, en désactivant la recherche ou en renvoyant moins de résultats de recherche, ou en désactivant certaines fonctionnalités coûteuses ou non essentielles. L'accent doit être mis sur la suppression des fonctionnalités qui peuvent être supprimées facilement et en toute sécurité, avec un impact minimal sur l'activité.

Améliorer

Utiliser un réseau de diffusion de contenu (CDN)

La diffusion d'éléments statiques peut être déchargée de votre serveur vers un réseau de diffusion de contenu (CDN), ce qui réduit la charge.

La fonction principale d'un CDN est de diffuser rapidement du contenu aux utilisateurs en fournissant un vaste réseau de serveurs situés à proximité des utilisateurs. Cependant, la plupart des CDN proposent également des fonctionnalités supplémentaires liées aux performances, telles que la compression, l'équilibrage de charge et l'optimisation des contenus multimédias.

Configurer un CDN

Les CDN bénéficient de l'évolutivité. Il est donc rarement judicieux d'exploiter votre propre CDN. Une configuration CDN de base est assez rapide à mettre en place (environ 30 minutes) et consiste à mettre à jour les enregistrements DNS pour qu'ils pointent vers le CDN.

Optimiser l'utilisation du CDN

Diagnostic

Identifiez les ressources qui ne sont pas diffusées à partir d'un CDN (mais qui devraient l'être) en exécutant WebPageTest. Sur la page des résultats, cliquez sur le carré au-dessus de "Utilisation efficace du CDN" pour afficher la liste des ressources qui doivent être diffusées à partir d'un CDN.

Flèche pointant vers le bouton "Utilisation efficace du CDN"
Résultats WebPageTest

Solution

Si une ressource n'est pas mise en cache par le CDN, vérifiez que les conditions suivantes sont remplies :

Faire évoluer les ressources de calcul

La décision de faire évoluer les ressources de calcul doit être prise avec précaution. Bien qu'il soit souvent nécessaire de faire évoluer les ressources de calcul, le faire prématurément peut générer une complexité architecturale et des coûts financiers inutiles.

Diagnostic

Un Time to First Byte (TTFB) élevé peut indiquer qu'un serveur approche de sa capacité maximale. Vous trouverez ces informations dans l'audit Lighthouse Réduire les temps de réponse du serveur (TTFB).

Pour approfondir l'enquête, utilisez un outil de surveillance pour évaluer l'utilisation du processeur. Si l'utilisation actuelle ou prévue du processeur dépasse 80 %, vous devriez envisager d'augmenter le nombre de serveurs.

Solution

L'ajout d'un équilibreur de charge permet de répartir le trafic sur plusieurs serveurs. Un équilibreur de charge se trouve devant un pool de serveurs et achemine le trafic vers le serveur approprié. Les fournisseurs de services cloud proposent leurs propres équilibreurs de charge (GCP, AWS, Azure), mais vous pouvez également configurer le vôtre à l'aide de HAProxy ou de NGINX. Une fois l'équilibreur de charge en place, vous pouvez ajouter des serveurs supplémentaires.

En plus de l'équilibrage de charge, la plupart des fournisseurs de services cloud proposent l'autoscaling (GCP, AWS, Azure). L'autoscaling fonctionne en conjonction avec l'équilibrage de charge. Il effectue automatiquement un scaling à la hausse ou à la baisse des ressources de calcul en fonction de la demande à un moment donné. Cela dit, l'autoscaling n'est pas magique : la mise en ligne de nouvelles instances prend du temps et nécessite une configuration importante. En raison de la complexité supplémentaire qu'implique l'autoscaling, il convient d'envisager d'abord une configuration plus simple basée sur un équilibreur de charge.

Autoriser la compression

Les ressources textuelles doivent être compressées à l'aide de gzip ou de brotli. Gzip peut réduire la taille de transfert de ces ressources d'environ 70 %.

Diagnostic

Utilisez l'audit Activer la compression de texte de Lighthouse pour identifier les ressources à compresser.

Solution

Activez la compression en mettant à jour la configuration de votre serveur. Instructions :

Optimiser les images et les contenus multimédias

Les images représentent la majeure partie de la taille des fichiers de la plupart des sites Web. L'optimisation des images peut réduire rapidement et considérablement la taille d'un site.

Diagnostic

Lighthouse propose différents audits qui signalent les optimisations d'image potentielles. Une autre stratégie consiste à utiliser DevTools pour identifier les fichiers image les plus volumineux. Ces images seront probablement de bons candidats à l'optimisation.

Audits Lighthouse pertinents :

Workflow des outils pour les développeurs Chrome :

Solution

Si vous manquez de temps…

Concentrez-vous sur l'identification des images volumineuses et fréquemment chargées, et optimisez-les manuellement à l'aide d'un outil tel que Squoosh. Les images héros sont souvent de bons candidats pour l'optimisation.

À retenir :

  • Taille : les images ne doivent pas être plus grandes que nécessaire.
  • Compression : en règle générale, un niveau de qualité de 80 à 85 aura un effet minimal sur la qualité de l'image, tout en réduisant la taille du fichier de 30 à 40 %.
  • Format : utilisez le format JPEG pour les photos plutôt que PNG, et le format MP4 pour le contenu animé plutôt que GIF.

Si vous avez plus de temps…

Envisagez de configurer un CDN d'images si les images représentent une part importante de votre site. Les CDN d'images sont conçus pour diffuser et optimiser les images, et ils déchargent le serveur d'origine de la diffusion des images. La configuration d'un CDN d'images est simple, mais nécessite de mettre à jour les URL d'images existantes pour qu'elles pointent vers le CDN d'images.

Autres références :

Minimiser le code JS et CSS

La minimisation supprime les caractères inutiles du code JavaScript et CSS.

Diagnostic

Utilisez les audits Lighthouse Minifier le CSS et Minifier le JavaScript pour identifier les ressources qui doivent être minifiées.

Solution

Si vous manquez de temps, concentrez-vous sur la minimisation de votre code JavaScript. La plupart des sites comportent plus de code JavaScript que de code CSS. Cette opération aura donc un impact plus important.

Surveillance

Les outils de surveillance des serveurs fournissent des fonctionnalités de collecte de données, des tableaux de bord et des alertes concernant les performances des serveurs. Leur utilisation peut aider à prévenir et à atténuer les futurs problèmes de performances du serveur.

Une configuration de surveillance doit être aussi simple que possible. La collecte de données et les alertes excessives ont un coût : plus la portée ou la fréquence de la collecte de données est importante, plus la collecte et le stockage sont coûteux. De plus, un nombre excessif d'alertes entraîne inévitablement l'ignorance de certaines pages.

Les alertes doivent utiliser des métriques qui détectent les problèmes de manière cohérente et précise. Le temps de réponse du serveur (latence) est une métrique qui fonctionne particulièrement bien pour cela : il détecte un grand nombre de problèmes et est directement corrélé à l'expérience utilisateur. Les alertes basées sur des métriques de niveau inférieur, comme l'utilisation du processeur, peuvent être un complément utile, mais elles ne détectent qu'un sous-ensemble plus restreint de problèmes. De plus, les alertes doivent être basées sur les performances observées à la fin (en d'autres termes, les 95e ou 99e centiles), plutôt que sur les moyennes. Sinon, les moyennes peuvent facilement masquer des problèmes qui n'affectent pas tous les utilisateurs.

Solution

Tous les principaux fournisseurs de services cloud proposent leurs propres outils de surveillance (GCP, AWS, Azure). En outre, Netdata est une excellente alternative sans frais et Open Source. Quel que soit l'outil que vous choisissez, vous devez installer l'agent de surveillance de l'outil sur chaque serveur que vous souhaitez surveiller. Une fois l'opération terminée, veillez à configurer les alertes.

Instructions :