Skip to main content

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.

ping 192.168.200.197
Pinging host 192.168.200.197 : 192.168.200.197
ICMP Echo Reply:TTL 53 time = 84 ms
ICMP Echo Reply:TTL 53 time = 80 ms
ICMP Echo Reply:TTL 53 time = 81 ms
ICMP Echo Reply:TTL 53 time = 96 ms
Host 192.168.200.197 replied to all 4 of the 4 pings

 

Malheureusement, il est de plus en plus fréquent que les réseaux bloquent les paquets ping, ou que les hôtes les ignorent, vous pouvez même dire au STCP de les ignorer (à partir de 15.3, 16.2 et 17x). Si vous ne pouvez pas utiliser le ping, vous pouvez utiliser packet_monitor pour chronométrer le temps qu'il faut pour obtenir une réponse à une demande de connexion. Par exemple, lancez packet_monitor avec la commande "start_process 'packet_monitor -numeric -time_stamp -filter -host A.B.C.D -port NNN' -privileged”. Ensuite, tapez la commande "telnet A.B.C.D NNN”. Vous devez faire plusieurs connexions et obtenir une moyenne. Remarquez que je me connecte à un port inutilisé sur l'hôte distant. Cela réduit le nombre de paquets dans la trace, mais si un pare-feu bloque le port, vous devrez peut-être utiliser un port actif.

 

start_process 'packet_monitor -numeric -time_stamp -filter -host 192.168.200.197
+ -port 6666' -privileged
ready 09:12:42
telnet 192.168.200.197 6666
Trying...
telnet: Unable to connect to remote host: The connection was refused.
ready 09:12:53
telnet 192.168.200.197 6666
Trying...
telnet: Unable to connect to remote host: The connection was refused.
ready 09:12:56
telnet 192.168.200.197 6666
Trying...
telnet: Unable to connect to remote host: The connection was refused.
ready 09:12:58
telnet 192.168.200.197 6666
Trying...
telnet: Unable to connect to remote host: The connection was refused.
ready 09:12:58
stop_process packet_monitor -no_ask
Stopping Noah_Davids.CAC (packet_monitor).
ready 09:13:07
d packet_monitor.out
%phx_vos#m16_mas>SysAdmin>Noah_Davids>packet_monitor.out 09-11-13 09:13:17 mst
Noah_Davids.CAC logged in on %phx_vos#m16 at 09-11-13 09:12:42 mst.
packet_monitor -numeric -time_stamp -filter -host 192.168.200.197 -port 6666
***********************************************************
WARNING: failure to specify a specific interface will cause
packet_monitor to bind to ALL interfaces on the module,
greatly increasing the amount of Streams memory used!!!
***********************************************************
dir                                                 icmp type
+     tcp
hh:mm:ss.ttt    len proto source             destination         src port dst p
+ort type
9:12:52.984 T 0004 TCP 172.16.77.128       192.168.200.197           62515
+ 6666 S
9:12:53.067 R 0000 TCP 192.168.200.197     172.16.77.128              6666
+ 62515 RA
9:12:56.643 T 0004 TCP 172.16.77.128       192.168.200.197           62516
+ 6666 S
9:12:56.724 R 0000 TCP 192.168.200.197     172.16.77.128              6666
+ 62516 RA
9:12:58.003 T 0004 TCP 172.16.77.128       192.168.200.197           62517
+ 6666 S
9:12:58.086 R 0000 TCP 192.168.200.197     172.16.77.128              6666
+ 62517 RA
9:12:58.805 T 0004 TCP 172.16.77.128       192.168.200.197           62518
+ 6666 S
9:12:58.887 R 0000 TCP 192.168.200.197     172.16.77.128              6666
+ 62518 RA
ready 09:13:07
Process finished.
Terminating Noah_Davids.CAC (packet_monitor). Process stopped by Noah_Davids.CA
+C.

 

Latency times:   58.887 - 58.805 = 0.082 == 82ms
58.086 - 58.003 = 0.083 == 83ms
56.724 - 56.643 = 0.081 == 81ms
53.067 - 52.984 = 0.083 == 83ms

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.

stcp_tping 192.168.200.197 23 1
tping 192.168.200.197 23 1
Success/Tries=Percent    min/average/max success times
1/1=100.000%             83.284/83.284/83.284     Connection in 83.284 ms
2/2=100.000%             81.697/82.490/83.284     Connection in 81.697 ms
3/3=100.000%             80.858/81.946/83.284     Connection in 80.858 ms
4/4=100.000%             80.858/81.895/83.284     Connection in 81.743 ms
^C

 

Comment pouvez-vous estimer la latence si vous ne disposez pas déjà des systèmes de mesure ? Le plus simple est de trouver un système dans la même zone géographique et de mesurer la latence par rapport à celui-ci. Vous obtiendrez ainsi une estimation très approximative. J'aime utiliser les collèges et les universités car je sais où ils sont situés et il y a de fortes chances qu'ils hébergent leurs propres systèmes sur le campus et, du moins les grandes universités, disposent probablement de liaisons Internet à haut débit. Le site web http://www.utexas.edu/world/univ/state/ répertorie les sites web de nombreuses universités par État. Le site web http://www.bulter.nl/universities/ répertorie les sites web des universités du monde entier par pays. Gardez à l'esprit qu'il peut y avoir une différence importante entre la communication sur un VPN d'entreprise et sur Internet.

 

Comment pouvez-vous résoudre le problème ? Vous ne le pouvez probablement pas. Vous pouvez avoir un certain contrôle sur la largeur de bande de certains liens et peut-être sur certains appareils du réseau, mais vous n'avez certainement aucun contrôle sur la distance. Ce que vous pouvez faire, c'est modifier l'application pour qu'elle soit moins sensible à la latence en réduisant le nombre de tours nécessaires.

 

Si vous utilisez OSL pour déplacer des fichiers volumineux sur de longues distances, tout ce que je peux vous dire, c'est de ne pas le faire. Selon le type de fichier, vous pouvez utiliser le FTP, ou le SFTP ou le SCP. Sinon, le site ftp Stratus dispose d'une application appelée tcp_save(ftp://ftp.stratus.com/vos/network/tcp_save.save.evf.gz) qui vous permet de copier efficacement un fichier via TCP sans utiliser OSL. Elle nécessite une certaine configuration mais peut réduire considérablement le temps de copie des fichiers volumineux.

 

2024 Stratus Technologies.