Problèmes de performance et de latence des applications

L'impact de la latence de la couche de communication est généralement sous-estimé lorsque l'on tente de résoudre les problèmes de performance des applications, mais une bonne compréhension est essentielle si vous voulez orienter vos efforts vers des solutions pratiques.

Tout d'abord, par latence de la couche de communication, j'entends le temps qu'il faut à un paquet pour aller du système local au système distant et revenir. Le principal facteur de latence de la couche de communication est la distance, du moins pour les hôtes géographiquement séparés. L'autre élément important est le nombre de dispositifs entre les hôtes locaux et distants qui traitent les paquets ; cela inclut des choses comme les routeurs et les pare-feu. La largeur de bande des liens joue un rôle, mais pas aussi important que la plupart des gens le pensent. La largeur de bande affecte le délai d'insertion - le temps qu'il faut pour mettre un paquet sur le fil mais le signal sur le fil voyage à une vitesse basée sur le support et non sur la largeur de bande. Pour la suite de cette discussion, je me contenterai d'utiliser la latence lorsque je parle de la latence de la couche de communication.

Pour démontrer les effets de la latence sur votre demande, disons que vous entrez des données dans une demande de client et que vous appuyez sur "retour". L'application cliente envoie un message à une application serveur, attend une réponse puis envoie un autre message, attend une réponse, etc. pendant un nombre N de "tours". À la fin de N tours, l'application cliente vous présente les résultats.

Supposons que 10 tours sont nécessaires et qu'il faut 1 ms à l'application serveur pour traiter le message du client et renvoyer une réponse. Avec une latence de 1 ms, vous obtenez un temps de réponse de 10 * (1 ms + 1 ms) ou 20 ms. Maintenant, prenez l'avion et allez à Chicago, le serveur reste à Boston. Vous avez donc une latence de 50 ms et un temps de réponse de 10 * (50 ms + 1 ms) ou 550 ms. C'est suffisant pour être perceptible mais pas douloureux. Augmentez le nombre de tours à 100 et vous avez maintenant un temps de réponse douloureux de 5,5 secondes. Vous pouvez penser que 100 tours est excessif, mais certaines requêtes de base de données ou applications qui remplissent des formulaires complexes peuvent le faire. Savez-vous combien de tours vos demandes nécessitent ?
La copie de fichiers via OSL présente également ce comportement. OSL enverra un fichier en 4K transactions. Chaque transaction nécessite une réponse, de sorte qu'un fichier de 1 000 000 d'octets nécessitera 1 000 000 / 4 096 = 245 transactions ou tours pour utiliser la nomenclature du paragraphe précédent. Là encore, en supposant que la transaction soit traitée en 1ms et que le temps de latence soit de 1ms, le fichier copy_file prendra 490ms. Si nous augmentons la latence à 50 ms, il faudra 12,495 secondes. Si nous augmentons le fichier à 1 000 000 000 d'octets, il faudra 244 141 transactions ; avec des temps correspondants de 488,282 secondes pour une latence de 1 ms et de 12 451,191 secondes ou presque 3,5 heures pour une latence de 50 ms.

Le moyen le plus simple de mesurer la latence est le ping.

Vous pouvez également utiliser un programme que j'ai écrit qui chronomètre les connexions sans avoir besoin d'utiliser packet_monitor. Voir http://members.cox.net/ndav1/self_published/stcp_tping.doc. La commande stcp_tping nécessite que vous vous connectiez à un port actif sur l'hôte distant. Dans ce cas, j'utilise le port 23 (telnet) mais n'importe quel port actif fonctionnera. Le chiffre 1 à la fin de la commande indique qu'une requête sera envoyée une fois par seconde.