Les clients font face à une latence élevée lors de la connexion à des applications web exécutées sur des instances EC2 enregistrées sur un équilibreur de charge ELB (Elastic Load Balancing).

Une latence élevée peut être due à différents facteurs tels que :

  • Connectivité réseau
  • Configuration ELB
  • Problèmes liés au serveur d'application web principal , notamment :
    • Utilisation de la mémoire  : l'une des causes les plus communes de latence pour une application web est la consommation de la totalité ou de la majeure partie de la mémoire physique (RAM) disponible sur l'instance EC2 hôte.
    • Utilisation de l'UC : une utilisation intensive de l'unité centrale sur l'instance EC2 hôte peut affecter de manière significative les performances de l'application web et, dans certains cas, provoquer une défaillance du serveur.
    • Configuration du serveur web : si un serveur d'application web principal présente une latence élevée bien qu'il n'y ait pas d'utilisation excessive de la mémoire ou de l'unité centrale, il convient de vérifier la configuration du serveur web afin de détecter les problèmes potentiels.
    • Dépendances d'application web : s'il est établi que la latence élevée d'un serveur d'application web principal n'est pas due à l'utilisation excessive de la mémoire ou de l'unité centrale, ni à une configuration erronée du serveur web, il est possible que les dépendances d'application web telles que les bases de données externes ou les compartiments Amazon S3 soient à l'origine de la dégradation des performances.

Effectuez les étapes suivantes pour déterminer la cause d'une latence élevée :

Exécutez une commande curl Linux pour mesurer le premier octet de la réponse et déterminer si un ou plusieurs serveurs d'application web présentent une latence élevée :

elb-latency-1

Vous pouvez également identifier les serveurs d'application web principaux présentant une latence élevée en consultant le journal d'accès ELB et en vérifiant lesquels sont associés à une valeur élevée de « temps de traitement principal ».

Concentrez le dépannage d'application web sur tous les serveurs principaux présentant une latence élevée.

La métrique de latence représente le temps écoulé, en secondes, entre le moment où la demande quitte l'équilibreur de charge et celui où ce dernier reçoit une réponse d'une instance enregistrée. La statistique préférée pour cette métrique est average, qui indique la latence moyenne pour toutes les requêtes. Une valeur moyenne de latence élevée indique généralement un problème au niveau des serveurs principaux plutôt qu'un problème lié à l'équilibreur de charge. Vérifiez la statistique maximum pour déterminer le nombre de points de données de latence qui atteignent ou dépassent la valeur du délai d'attente d'inactivité de l'équilibreur de charge. Lorsque les points de données de latence sont égaux ou supérieurs à la valeur du délai d'inactivité, il est probable que certaines requêtes expirent, déclenchant l'envoi d'un message HTTP 504 aux clients.

elb-latency-2

Si la statistique maximum de latence présente un pic à intervalles réguliers ou suit un modèle particulier, cela peut indiquer des problèmes de performances sur les serveurs d'applications web principaux ou les serveurs de dépendance d'application liés à une surcharge lors de l'exécution de tâches planifiées.

Cette métrique fournit le nombre total de requêtes en attente de soumission (placées dans la file d'attente) pour une instance enregistrée. La valeur maximale de SurgeQueueLength est 1 204. Lorsque la valeur SurgeQueueLength maximale est dépassée, la statistique sum de la métrique SpilloverCount commence à calculer le nombre total de requêtes rejetées en raison d'une file d'attente saturée. Pour en savoir plus sur la résolution des problèmes liés à une valeur SurgeQueueLength élevée, consultez Comment résoudre les problèmes de capacité liés à Elastic Load Balancing ?

Ouvrez le journal d'accès ELB pour identifier la cause de latence élevée. Le journal d'accès capture la valeur « backend_processing_time » qui enregistre le temps total écoulé (en secondes) entre le moment où l'équilibreur de charge envoie la requête (écouteur HTTP)/le premier octet (écouteur TCP) à une instance enregistrée et celui où l'instance commence à envoyer les en-têtes/le premier octet de la réponse. Pour plus de détails sur le journal d'accès, consultez la section Surveiller votre équilibreur de charge à l'aide des journaux d'accès Elastic Load Balancing. Si vous remarquez que les valeurs de « request_processing_time » et « response_processing_time » sont plus élevées que prévu, contactez AWS Support.

Vérifiez la mémoire disponible  : le manque de mémoire peut être à l'origine d'une latence élevée. Lorsque cela se produit, le système d'exploitation tente de libérer de la RAM en déplaçant une partie vers l'espace d'échange, une quantité d'espace réservée sur votre disque dur. Un serveur d'application web doit éviter de déplacer la mémoire sur disque, car cette opération augmente la latence de chaque requête de manière significative. Dans ce cas, l'utilisateur peut également tenter de recharger les pages, ce qui augmente la charge et aggrave le problème. Surveillez le nombre de processus Apache et la quantité totale de mémoire RAM utilisée. Exécutez la commande Linux suivante pour afficher le nombre de processus Apache et la quantité totale de mémoire RAM utilisée, dans un tableau qui est mis à jour toutes les secondes :

watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"

Lors de l'exécution de cette commande, la sortie générée est semblable à ce qui suit :

elb-latency-3

Vérifiez l'utilisation de l'UC  : l'unité centrale du serveur web est utilisée pour obtenir et servir les pages web à vos visiteurs, que celles-ci soient statiques ou dynamiques. Plus de cycles ou de ressources processeur sont utilisés lorsque vos pages web sont servies de manière dynamique à partir d'une base de données ou d'un script. Vérifiez la métrique CloudWatch d'utilisation du processeur pour en surveiller l'utilisation et déterminer si la mise à niveau vers un type d'instance plus grande est nécessaire. La statistique average vous donnera une idée générale de l'utilisation globale de l'UC. Vous pouvez également calculer la statistique maximum pour vérifier les pics d'utilisation de l'UC, susceptibles d'engendrer des problèmes de latence.

elb-latency-4

Vérifiez la configuration du serveur web  : la plupart des serveurs web fournissent un paramètre MaxClient configurable qui définit le nombre maximal de processus pouvant être créés pour un serveur web. Ce paramètre limite le nombre de clients pouvant être servis simultanément par votre serveur web. Si votre serveur web dispose d'une quantité importante de RAM et de ressources processeur, mais que la latence est malgré tout élevée, il est conseillé de vérifier cette valeur pour déterminer si elle est trop basse. Si tel est le cas, les connexions client sont renvoyées vers la file d'attente et peuvent finalement expirer.

En reprenant l'exemple du serveur web Apache, si ce serveur utilise le module multi-processus (MPM) Prefork, il est possible de calculer le nombre de processus lancés par Apache afin d'établir le nombre de connexions simultanées. En effet, le module multi-processus Prefork utilise plusieurs processus enfant avec un thread chacun et chaque processus gère une connexion à la fois.

Exécutez la commande suivante pour déterminer le nombre de processus créés par un serveur web Apache (httpd) :

[root@ip-192.168.1.50  conf]# ps aux | grep httpd | wc -l 15

La sortie de cette commande vous permet de comparer le nombre total de processus Apache avec le paramètre MaxClient dans le fichier de configuration du serveur web Apache :

elb-latency-5

Si le nombre de processus Apache atteint systématiquement la valeur définie pour MaxClient, il est probable que vos utilisateurs finaux rencontrent un problème de lenteur.

Vérifiez les dépendances du serveur web : si l'UC, la mémoire et la configuration de vos instances principales ne posent pas problème, il peut être utile de vérifier les dépendances. Voici quelques points à vérifier lors de l'évaluation des dépendances d'un serveur web :

  • Vos serveurs web dépendent-ils d'une base de données partagée, susceptible d'être surchargée ?
  • Les serveurs web se connectent-ils à des ressources externes (par exemple, un compartiment S3) ?
  • Comment votre serveur web se connecte-t-il aux ressources externes ? Par exemple, une connexion via une instance NAT de taille inadaptée peut limiter le débit nécessaire pour des performances adéquates.
  • Les serveurs web appellent-ils un service web distant dont l'exécution est lente ?
  • Les serveurs web se connectent-ils aux ressources externes par le biais d'un équilibreur de charge principal servant de serveur proxy aux autres instances principales ?

Il ne s'agit là que de quelques exemples d'éléments à prendre en considération lors de l'évaluation de l'impact des dépendances d'un serveur web sur les performances et la latence élevée du serveur d'application web.

Elastic Load Balancing, dépannage de serveur principal, maxclient, utilisation de la RAM, métrique de latence CloudWatch, utilisation de l'UC, contrôle de processus


Cette page vous a-t-elle été utile ? Oui | Non

Retour au Centre de connaissances AWS Support

Vous avez besoin d'aide ? Consultez le site du Centre AWS Support.