Netperf, mesurer la performance de votre réseau en ligne de commande
Netperf est un logiciel sous licence libre (GPL) permettant de simuler du trafic entre deux points d'un réseau. Edité par la société HP, la dernière version disponible (2.5.0) date de juillet 2011.
Contrairement à des logiciels comme Iperf qui se limite a une mesure de la bande passante et du délais, NetPerf permet, en plus du transfert de données, de simuler des transactions TCP et UDP. Nous allons voir dans ce billet comment installer et utiliser NetPerf pour optimiser notre réseau.
Mesure du débit utile
Le test le plus courant demandé à NetPerf est de mesurer le débit de notre réseau, c'est à dire la quantité d'information (donnée) que l'on peut transporter en une seconde d'un point A (client) vers un point B (serveur). Nous utiliserons pour cela les scénarios TCP_STREAM (pour un transfert TCP) ou UDP_STREAM (pour un transfert UDP).
Lors de l'installation sous Ubuntu, le daemon serveur est lancé automatiquement en écioutant sur le port 12345 (il faut pensé à ajouter les règles de firewall qui vont bien pour autoriser le/les clients NetPerf à se connecter sur le serveur). A vérifier avec la commande "ps auxw | grep netserver" avant de saisir la commande suivante:
serveur# sudo netserver
Pour la suite du billet je prendrai comme hypothèse le fait que le serveur est lancé.
Ensuite on lance le client:
client# netperf -H server -t TCP_STREAM
Après quelques secondes, le client devrait afficher:
1 2 3 4 5 6 | <span style="color: #808080;">TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to bilbo.nicolargo.com (92.243.16.42) port 0 AF_INET : demo</span> <span style="color: #808080;">Recv Send Send</span> <span style="color: #808080;">Socket Socket Message Elapsed</span> <span style="color: #808080;">Size Size Size Time Throughput</span> <span style="color: #808080;">bytes bytes bytes secs. 10^6bits/sec</span> <span style="color: #808080;">87380 16384 16384 10.46 <strong>3.43</strong></span> |
On a donc un débit d'environ 3.43Mbit/sec.
Optimisation du débit utile
Comme vous le savez (ou pas), le débit utile en TCP peut être optimisé en jouant sur la valeur des "buffers" de réception et d'émission (dans les noyaux Linux récents, ces valeurs sont calculés et adaptés dynamiquement). NetPerf peut être utilisé pour tester les valeurs de "buffers" idéales pour votre réseau en procédant de la manière suivante:
On fait le test initial (sans optimisation):
client# netstat -s -p tcp > beforestat
client# netperf -H server -t TCP_STREAM > beforeres
On fait le test final (avec optimisation).
On peut par exemple utiliser pour cela les options -s et -S qui fixent respectivement la taille des "buffers" du client et du serveur. Ou bien ajouter le support des options CORK pour l'optimisation de la taille des MSS (-C) et de l'algorithme Nagle (-D).
Il faut faire attention de mettre ces options après l'option -- (pour préciser que ces options sont celle de TCP_STREAM).
client# netperf -H server -t TCP_STREAM -- -s 128k -S 128k -C -D > afterres
client# netstat -s -p tcp > afterstat
On peut ensuite comparer les deux fichiers de résultats.
# diff beforeres afterres
> 87380 16384 16384 10.43 3.43
---
< 87380 16384 16384 10.27 3.73
Soit un gain de 300 Kbps.
Pour comparer les stats TCP on peut récupérer le programme C "BeforeAfter" de HP:
# ./beforeafter beforestat afterstat
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 | <span style="color: #888888;">TcpExt:</span> <span style="color: #888888;">0 TCP sockets finished time wait in fast timer</span> <span style="color: #888888;">1 time wait sockets recycled by time stamp</span> <span style="color: #888888;">3 accusés de réception envoyés en retard</span> <span style="color: #888888;">0 delayed acks further delayed because of locked socket</span> <span style="color: #888888;">Le mode ACK rapide a été activé 0 fois</span> <span style="color: #888888;">80 paquets directement mis en attente dans la file d'attente recvmsg.</span> <span style="color: #888888;">0 bytes directly in process context from backlog</span> <span style="color: #888888;">4660 bytes directly received in process context from prequeue</span> <span style="color: #888888;">19 en-têtes de paquets prédits</span> <span style="color: #888888;">3 packets header predicted and directly queued to user</span> <span style="color: #888888;">364 acknowledgments not containing data payload received</span> <span style="color: #888888;">1412 accusés de réception prédits</span> <span style="color: #888888;">0 times recovered from packet loss due to fast retransmit</span> <span style="color: #888888;">14 times recovered from packet loss by selective acknowledgements</span> <span style="color: #888888;">0 bad SACK blocks received</span> <span style="color: #888888;">0 congestion windows recovered without slow start after partial ack</span> <span style="color: #888888;">9 TCP data loss events</span> <span style="color: #888888;">0 timeouts after reno fast retransmit</span> <span style="color: #888888;">0 timeouts after SACK recovery</span> <span style="color: #888888;">0 timeouts in loss state</span> <span style="color: #888888;">15 fast retransmits</span> <span style="color: #888888;">0 retransmits in slow start</span> <span style="color: #888888;">1 other TCP timeouts</span> <span style="color: #888888;">0 SACK retransmits failed</span> <span style="color: #888888;">0 times receiver scheduled too late for direct processing</span> <span style="color: #888888;">0 DSACKs sent for old packets</span> <span style="color: #888888;">0 DSACKs sent for out of order packets</span> <span style="color: #888888;">0 DSACKs received</span> <span style="color: #888888;">0 connections reset due to unexpected data</span> <span style="color: #888888;">0 connections reset due to early user close</span> <span style="color: #888888;">0 connections aborted due to timeout</span> <span style="color: #888888;">TCPSACKDiscard: 0</span> <span style="color: #888888;">TCPDSACKIgnoredOld: 0</span> <span style="color: #888888;">TCPDSACKIgnoredNoUndo: 0</span> <span style="color: #888888;">TCPSackShifted: 130</span> <span style="color: #888888;">TCPSackMerged: 80</span> <span style="color: #888888;">TCPSackShiftFallback: 27</span> |
Pour effectuer un test de débit dans le sens inverse (c'est à dire du serveur/netserver vers le client/netperf), on peur utiliser l'option TCP_MAERTS.
client# netperf -H server -t TCP_MAERTS
Mesure des transactions
Le débit utile n'est pas forcement une mesure capitale dans les performances d'un réseau. Si l'on prend l'exemple d'un trafic de type Web (HTML), c'est la capacité a faire rapidement des transactions (requêtes/réponses) qui est importante. NetPerf propose donc de tester ce type de transaction avec les scénarios TCP_RR (transactions TCP) ou UDP_RR (transaction UDP).
On lance le client:
client# netperf -H server -t TCP_RR
Après quelques secondes, le client devrait afficher:
1 2 3 4 5 6 7 | <span style="color: #888888;">TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to bilbo.nicolargo.com (92.243.16.42) port 0 AF_INET : demo</span> <span style="color: #888888;">Local /Remote</span> <span style="color: #888888;">Socket Size Request Resp. Elapsed Trans.</span> <span style="color: #888888;">Send Recv Size Size Time Rate</span> <span style="color: #888888;">bytes Bytes bytes bytes secs. per sec</span> <span style="color: #888888;">16384 87380 1 1 10.00 <strong>47.40</strong></span> <span style="color: #888888;">16384 87380</span> |
On a donc une mesure de 47 transactions par seconde.
Optimisation des transactions
Là encore, il est possible de tester différentes optimisation au niveau du protocole TCP. Par exemple, les "buffers" comme nous l'avons vu au chapitre précédant (option -s et -S). Pour coller au plus près au trafic généré par vos applications, NetPerf permet également dans ce mode (TCP-RR) de fixer la taille des requêtes de la transaction avec l'option -r. Celle-ci prend deux argument: le premier est la taille de la requête, le second la taille de la réponse.
Par exemple pour simuler des transactions dont la requête a une taille de 64 octets et une réponse de 64Koctets, il faut saisir la commande suivante:
client# netperf -H server -t TCP_RR -- -r 64,64k
On peut ensuite essayer des optimisations au niveau des tailles de buffers (comme dans le chapitre précédents):
client# netperf -H server -t TCP_RR -- -r 64,64k -s 128k -S 128k -C -D
Conclusion
Ce billet n'est qu'une introduction au logiciel NetPerf. Si vous souhaitez approfondir le sujet, je vous conseille la lecture de la documentation officielle (en Anglais).
Créateur de blog de Nicolargo, je suis un partisan des logiciels libres et un passionné des nouvelles technologies.
Suivre @nicolargo sur Twitter S'abonner au flux RSS du blog
Twitter: 
Rss:
Commentaires (de mes chers lecteurs):
Bonjour,
très pratique ce logiciel, mais existe-il une version Windows du moins pour la partie cliente.
Merci.
En fait, ça fait globalement la même chose de iPerf, non?
@theclimber: pas tout à fait. En effet NetPerf permet de simuler des transactions TCP ou UDP, pas Iperf…
Bonjour Nicolas (j’espère que c’est çà d’ailleurs),
bon juste pour te dire deux choses:
. ton blog est excellent: je découvre en ce moment la mine d’informations qu’il regorge
. peux tu juste actualiser cette page car il est à présent en version 2.5.0 depuis le 19 juillet dernier.
@+,
Merci !
C’est mis à jour.
Nicolas (je confirme
)
merci pour tout NICOLARGO
connaissez-vous une application open-source permettant de surveiller un réseau électrique pour lutter contre les fraudes?