Résoudre un problème de serveur surchargé

Comment identifier et éliminer rapidement les goulots d'étranglement d'un serveur, 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 un problème de serveur surchargé en quatre étapes:

  1. Évaluation: identifiez le goulot d'étranglement du serveur.
  2. Stabiliser: mettez en œuvre des correctifs rapides pour atténuer l'impact.
  3. Amélioration: améliore et optimise les capacités du serveur.
  4. Surveiller: utilisez des outils automatisés pour éviter que les problèmes ne se reproduisent.

Évaluation

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

  • CPU: l'utilisation du CPU dépasse systématiquement 80% doit être examinée et corrigée. Les performances des serveurs se dégradent souvent une fois que l'utilisation du processeur atteint environ 80 à 90%, puis elles deviennent plus prononcées à mesure que l'utilisation se rapproche de 100%. L'utilisation du processeur lors du traitement d'une seule requête est négligeable, mais une utilisation à une échelle adaptée aux pics de trafic peut parfois surcharger un serveur. Le déchargement de la diffusion sur une autre infrastructure, la réduction des opérations coûteuses et la limitation du nombre de requêtes permettent de réduire l'utilisation du processeur.
  • Réseau: lors des périodes de trafic élevé, le débit réseau requis pour traiter les requêtes des utilisateurs peut dépasser la capacité. Certains sites, en fonction du fournisseur d'hébergement, peuvent également rencontrer des limites en termes de transfert de données cumulatif. Réduire la taille et la quantité des données transférées vers et depuis le serveur permet d'éliminer ce goulot d'étranglement.
  • Mémoire: lorsqu'un système n'a pas assez 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 la mémoire, ce qui peut ralentir toute une application. Si la mémoire est complètement épuisée, des erreurs de type Saturation de la mémoire peuvent se produire. L'ajustement de l'allocation de mémoire, la correction des fuites de mémoire et la mise à niveau de la mémoire peuvent éliminer ce goulot d'étranglement.
  • E/S disque: la vitesse à laquelle les données peuvent être lues ou écrites à partir du disque est limitée par le disque lui-même. Si les E/S disque constituent un goulot d'étranglement, l'augmentation de la quantité de données mises en cache en mémoire peut permettre de résoudre ce problème (mais cela augmente l'utilisation de la mémoire). Si cela ne fonctionne pas, il peut être nécessaire de mettre à niveau vos disques.

Les techniques présentées dans ce guide sont axées sur la résolution des goulots d'étranglement du processeur et du réseau. Pour la plupart des sites, le processeur et le réseau constituent les goulots d'étranglement les plus importants 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. Le cas échéant, ajoutez les données historiques de votre fournisseur d'hébergement ou de vos outils de surveillance.

Stabiliser

Une surcharge de serveur peut rapidement entraîner des échecs 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. Ce point 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, augmentant encore plus la charge du serveur.

Solution

Bien que le rejet d'une requête soit relativement peu coûteux, le meilleur moyen de protéger votre serveur consiste à 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

Cherchez 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), il n'est pas nécessaire de la demander 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. Auditer et corriger ces en-têtes améliorera la mise en cache.

Bien que les service workers puissent également être utilisés pour la mise en cache, ils font appel à un cache distinct et viennent compléter, et non remplacer, la mise en cache HTTP appropriée. 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 examinez l'audit Diffuser des éléments statiques avec une règle de cache efficace pour afficher la liste des ressources ayant une durée de vie (TTL) courte ou moyenne. Pour chaque ressource répertoriée, déterminez si la valeur TTL doit être augmentée. À titre indicatif:

  • Les ressources statiques doivent être mises en cache avec une longue valeur TTL (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 progressive

La dégradation progressive est la stratégie qui consiste à réduire temporairement les fonctionnalités afin d'éviter l'excès de charge d'un système. Ce concept peut être appliqué de différentes manières: par exemple, afficher une page de texte statique au lieu d'une application complète, désactiver la recherche ou renvoyer moins de résultats de recherche, ou désactiver 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'entreprise.

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 livrer rapidement du contenu aux utilisateurs en fournissant un vaste réseau de serveurs situés à proximité des utilisateurs. Cependant, la plupart des CDN offrent également des fonctionnalités supplémentaires liées aux performances, telles que la compression, l'équilibrage de charge et l'optimisation des médias.

Configurer un CDN

Les CDN bénéficient d'une grande évolutivité. Il est donc rarement judicieux d'exploiter votre propre CDN. Une configuration CDN de base est assez rapide (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 par un CDN (alors qu'elles devraient l'être) en exécutant WebPageTest. Sur la page de résultats, cliquez sur le carré au-dessus de "Utilisation efficace du CDN" pour afficher la liste des ressources à diffuser à partir d'un CDN.

Flèche pointant vers le bouton "Utilisation efficace du CDN"
Résultats de 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 d'effectuer le scaling des ressources de calcul doit être prise avec précaution. Bien qu'il soit souvent nécessaire de faire évoluer les ressources de calcul de manière prématurée, cela peut générer une complexité architecturale inutile et des coûts financiers inutiles.

Diagnostic

Un délai avant le premier octet élevé peut indiquer qu'un serveur s'approche de sa capacité maximale. Vous trouverez ces informations dans l'audit Lighthouse Réduire le temps de réponse du serveur (TTFB) de Lighthouse.

Pour approfondir l'analyse, utilisez un outil de surveillance afin d'évaluer l'utilisation du processeur. Si l'utilisation actuelle ou prévue du processeur dépasse 80 %, envisagez d'augmenter le nombre de vos serveurs.

Solution

L'ajout d'un équilibreur de charge permet de répartir le trafic entre plusieurs serveurs. Un équilibreur de charge est placé 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). Vous pouvez également configurer les vôtres à l'aide de HAProxy ou NGINX. Une fois l'équilibreur de charge en place, vous pouvez ajouter des serveurs supplémentaires.

Outre l'équilibrage de charge, la plupart des fournisseurs de services cloud proposent l'autoscaling (GCP, AWS, Azure). L'autoscaling fonctionne conjointement avec l'équilibrage de charge. L'autoscaling adapte automatiquement les ressources de calcul à la demande à un moment donné. Cela dit, l'autoscaling n'est pas magique. La mise en ligne des nouvelles instances prend du temps et nécessite une configuration importante. En raison de la complexité supplémentaire que représente l'autoscaling, une configuration plus simple basée sur un équilibreur de charge doit être envisagée en premier.

Autoriser la compression

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

Diagnostic

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

Solution

Mettez à jour la configuration de votre serveur pour autoriser la compression. Instructions :

Optimisez les images et les médias

Les images constituent la majorité de la taille des fichiers sur la plupart des sites Web. L'optimisation des images permet de réduire rapidement et de manière significative la taille d'un site.

Diagnostic

Lighthouse propose différents audits permettant de signaler d'éventuelles optimisations d'images. Une autre stratégie consiste à utiliser les outils de développement pour identifier les fichiers image les plus volumineux. Ces images seront probablement optimisées.

Audits Lighthouse pertinents:

Workflow des outils pour les développeurs Chrome:

Solution

Si votre temps est limité...

Concentrez-vous sur l'identification des images volumineuses et fréquemment chargées et sur leur optimisation manuelle à l'aide d'un outil tel que Squoosh. Les images principales se prêtent souvent à 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é compris entre 80 et 85 a un impact minimal sur la qualité de l'image tout en réduisant la taille des fichiers de 30 à 40 %.
  • Format: utilisez le format JPEG pour les photos plutôt que PNG. Utilisez le format MP4 pour le contenu animé plutôt que GIF.

Si vous avez plus de temps...

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

Autres références :

Réduire la taille des fichiers JS et CSS

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

Diagnostic

Utilisez les audits Lighthouse Minify CSS (Réduire la taille des ressources CSS) et Minify JavaScript (Minifier la taille de JavaScript) pour identifier les ressources qui doivent être minimisées.

Solution

Si vous disposez de peu de temps, concentrez-vous sur la réduction de la taille de votre code JavaScript. La plupart des sites ont plus de code JavaScript que CSS, ce qui a un impact plus important.

Surveiller

Les outils de surveillance des serveurs fournissent des données collecté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 des serveurs.

Une configuration de surveillance doit être aussi simple que possible. Une collecte de données et des alertes excessives ont des coûts: plus la collecte ou la fréquence de la collecte de données est importante, plus leur collecte et leur stockage coûtent cher. Une alerte excessive conduit inévitablement à des pages ignorées.

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 particulièrement efficace dans ce cas de figure: elle permet d'identifier une grande variété de problèmes et d'être directement corrélée à l'expérience utilisateur. Les alertes basées sur des métriques de niveau inférieur telles que l'utilisation du processeur peuvent être un complément utile, mais elles permettent de détecter un sous-ensemble plus restreint de problèmes. En outre, les alertes doivent être basées sur les performances observées en fin de ligne (c'est-à-dire 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). De plus, Netdata est une excellente alternative sans frais et Open Source. Quel que soit l'outil que vous choisissez, vous devrez 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 :