Comment résoudre les problèmes de latence élevée sur mon équlibreur de charge d'application ?

Brève description

Les causes possibles de latence élevée sur un Application Load Balancer incluent :

• Problèmes de connectivité réseau
• Utilisation élevée de la mémoire (RAM) sur les instances backend
• Utilisation élevée de l'UC sur les instances backend
• Configuration inappropriée du serveur Web sur les instances backend
• Problèmes liés aux dépendances d'application Web exécutées sur les instances backend, telles que des bases de données externes ou des compartiments Amazon Simple Storage Service (Amazon S3)

Résolution

1.    Recherchez les problèmes de connectivité réseau à l'aide des étapes de dépannage de la section Dépanner vos Application Load Balancers.

2.    Utilisez l'outil curl pour mesurer la réponse du premier octet et vérifier si la résolution DNS lente contribue à la latence.

curl -kso /dev/null https://www.example.com -w "==============\n\n 
| dnslookup: %{time_namelookup}\n 
| connect: %{time_connect}\n 
| appconnect: %{time_appconnect}\n 
| pretransfer: %{time_pretransfer}\n 
| starttransfer: %{time_starttransfer}\n 
| total: %{time_total}\n 
| size: %{size_download}\n 
| HTTPCode=%{http_code}\n\n"

Exemple de sortie :

 | dnslookup: 0.005330
 | connect: 0.006682
 | appconnect: 0.026540
 | pretransfer: 0.026636
 | starttransfer: 0.076980
 | total: 0.077111
 | size: 12130
 | HTTPCode=200

Effectuez ces tests par le biais de l'Application Load Balancer. Ensuite, effectuez les tests en contournant l'Application Load Balancer vers les cibles. Cette approche permet d'isoler le composant induisant la latence. Pour plus d'informations sur les fonctions de curl, consultez la section Comment utiliser les fonctions curl.

3.    Vérifiez la statistique Moyennede la métrique TargetResponseTime d'Amazon CloudWatch pour votre Application Load Balancer. Une valeur élevée signifie qu'il y a probablement un problème lié aux instances backend ou aux serveurs de dépendance d'application.

4.    Déterminez les instances backend qui rencontrent des problèmes de latence élevée en vérifiant les entrées des journaux d'accès de votre Application Load Balancer. Vérifiez target_processing_time pour rechercher les instances backend qui rencontrent des problèmes de latence. Vérifiez également les champs request_processing_time et response_processing_time afin de vérifier tout problème avec l'Application Load Balancer.

5.    Vérifiez la métrique CPUUtilization de CloudWatch de vos instances backend. Recherchez toute utilisation d'UC élevée ou les pics d'utilisation d'UC. En cas d'utilisation d'UC élevée, envisagez de recourir à des types d'instances plus importants.

6.    Vérifiez les problèmes de mémoire en examinant les processus Apache sur vos instances backend.

Exemple de commande :

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

Exemple de sortie :

Every 1.0s: echo –n 'Apache Processes: ' && ps –C apache2 –no-
headers | wc -1 && free –m
Apache Processes: 27
          total     used     free     shared     buffers     cached
Mem:      8204      7445     758      0          385         4567
-/+ buffers/cache:  2402     5801
Swap:     16383     189      16194

7.    Vérifiez le paramètre MaxClient pour les serveurs Web sur vos instances backend. Ce paramètre définit le nombre de demandes simultanées que l'instance peut servir. Pour les instances qui présentent une utilisation appropriée de mémoire et d'UC, mais une latence élevée, envisagez d'augmenter la valeur MaxClient.

Comparez le nombre de processus générés par Apache (httpd) avec le paramètre MaxClient. Si le nombre de processus Apache atteint fréquemment la valeur MaxClient, envisagez d'augmenter cette valeur.

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

<IfModule prefork.c>
StartServers         10
MinSpareServers      5
MaxSpareServers      10
ServerLimit          15
MaxClients           15
MaxRequestsPerChild  4000
</IfModule>

8.    Recherchez d'éventuelles dépendances de vos instances backend pouvant entraîner des problèmes de latence. Les dépendances peuvent inclure des bases de données partagées ou des ressources externes (telles que des compartiments Amazon S3). Les dépendances peuvent également inclure des connexions de ressources externes, telles que des instances de traduction d'adresses réseau (NAT), des services Web distants ou des serveurs proxy.

9.    Utilisez les outils Linux suivants afin d'identifier les obstacles aux performances sur le serveur.

uptime : affiche les moyennes de charge pour déterminer le nombre de tâches (processus) en attente d'exécution. Sur les systèmes Linux, ce nombre inclut les processus en attente d'exécution sur l'UC, ainsi que les processus bloqués dans les E/S sans interruption (généralement les E/S de disque). Ces données fournissent un aperçu de haut niveau de la charge de ressource (ou de la demande) qui doit être interprétée à l'aide d'autres outils. Lorsque les moyennes de charge Linux augmentent, la demande en ressources est plus élevée. Pour déterminer les ressources les plus demandées, vous devez utiliser d'autres métriques. Par exemple, pour les UC, vous pouvez utiliser mpstat -P ALL 1 pour mesurer l'utilisation par UC, ou top ou pidstat 1 pour mesurer l'utilisation de l'UC par processus.

mpstat -P ALL 1 : affiche les répartitions de temps de l'UC par UC, ce qui vous permet de vérifier un déséquilibre. Une seule UC à chaud peut être la preuve d'une application à thread unique.

pidstat 1 : affiche l'utilisation de l'UC par processus et un récapitulatif continu qui est utile pour consulter les modèles au fil du temps.

dmesg | tail : affiche les 10 derniers messages du système, le cas échéant. Recherchez les erreurs susceptibles de provoquer des problèmes de performances.

iostat -xz 1 : affiche la charge de travail appliquée aux périphériques de bloc (disques) et les performances qui en résultent.

free -m : affiche la quantité de mémoire libre. Vérifiez que la taille de ces nombres n'est pas proche de zéro, ce qui peut entraîner des E/S de disque plus élevées (confirmer à l'aide d'iostat) et des performances moindres.

sar -n DEV 1 : affiche le débit de l'interface réseau (rxko/s et txko/s) comme mesure de la charge de travail. Vérifiez si des limites ont été atteintes.

sar -n TCP, ETCP 1 : affiche les métriques TCP clés, y compris : active/s (nombre de connexions TCP locales par seconde), passive/s (nombre de connexions TCP lancées à distance par seconde) et retrans/s (nombre de retransmissions TCP par seconde).

iftop : affiche les connexions entre votre serveur et une adresse IP distante qui consomment le plus de bande passante. iftop est disponible dans un package portant le même nom sur les distributions Red Hat et Debian. Cependant, avec les distributions basées sur Red Hat, vous pouvez plutôt trouver iftop dans un référentiel tiers.

---