Etude de cas – Latence réseau dans un LAN Fibre

L’algorithme de Nagle a été inventé pour améliorer l’efficacité du protocole TCP lors de l’échange de paquets à charge utile faible (payload). C’est par exemple le cas de Telnet qui envoie chaque caractère tapé en temps réel.

Ainsi pour éviter une congestion du réseau inutile, le mécanisme de Nagle va utiliser une mémoire tampon (buffer) pour stocker les requêtes reçues dans la limite de 200 ms. Après quoi la réponse sera transmise. Il en résulte une latence réseau induite qui n’a plus lieu d’être en 2017 tant les bandes passantes et la qualité des interconnexions se sont améliorées. Pour illustration, la latence moyenne d’une liaison ADSL « grand public » est de 30-40 ms à destination de l’Europe.

Particulièrement connu dans le monde du jeu vidéo en ligne, l’algorithme de Nagle est régulièrement critiqué pour les dégradations de performance qu’il génère.

Contexte

Les utilisateurs constatent des lenteurs lors de l’accès à leur application principale. L’architecture de cette application est la suivante :

Cas d’usage

Pour rappel, la latence réseau – ou RTT (Round Trip Time) – est une métrique de performance purement réseau et ne reflète en aucun cas un comportement applicatif. De plus, sur un LAN fibré, le RTT  ne doit pas dépasser la milliseconde.

Le SRT (Service Response Time) est le temps de réponse nécessaire à un serveur pour répondre à une requête cliente. Il est représentatif d’une anomalie applicative.

Avec Performance Vision, graffons la performance des échanges entre les frontaux et la base de données, situés sur un même LAN relié en fibre :

On constate rapidement :

• Une latence réseau serveur (base de données) de 500 us en moyenne ;
• Une latence réseau client (frontaux) de 4 ms en moyenne ;
• Une performance de traitement du serveur (base de données) bonne et stable.

La latence réseau des frontaux est donc mauvaise.

Analysons maintenant de façon détaillée les paquets à l’aide de Wireshark :

En regardant d’encore plus près, on constate clairement les 199 ms d’acquittement réseau :

Les frontaux dégradent donc les performances globales de l’application en appliquant inutilement l’algorithme de Nagle.

Solutions

En désactivant le TCPNoDelay dans le système d’exploitations des frontaux applicatifs, il apparait nettement que la latence réseau disparait directement :

Par ailleurs, les accès Web des clients gagnent 20 à 50% de temps de réponse selon les requêtes.

Conclusion

Les comportements des systèmes d’exploitation sur TCP ne sont pas à négliger car il peuvent influer fortement sur les performances globales d’une application. Par ailleurs, sans une solution de visibilité réseau, il est très compliqué de détecter ce type d’anomalie car ces microflow sont perdus dans la masse.