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.4.5) date de janvier 2009.
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:
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 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 10.46 3.43
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
TcpExt: 0 TCP sockets finished time wait in fast timer 1 time wait sockets recycled by time stamp 3 accusés de réception envoyés en retard 0 delayed acks further delayed because of locked socket Le mode ACK rapide a été activé 0 fois 80 paquets directement mis en attente dans la file d'attente recvmsg. 0 bytes directly in process context from backlog 4660 bytes directly received in process context from prequeue 19 en-têtes de paquets prédits 3 packets header predicted and directly queued to user 364 acknowledgments not containing data payload received 1412 accusés de réception prédits 0 times recovered from packet loss due to fast retransmit 14 times recovered from packet loss by selective acknowledgements 0 bad SACK blocks received 0 congestion windows recovered without slow start after partial ack 9 TCP data loss events 0 timeouts after reno fast retransmit 0 timeouts after SACK recovery 0 timeouts in loss state 15 fast retransmits 0 retransmits in slow start 1 other TCP timeouts 0 SACK retransmits failed 0 times receiver scheduled too late for direct processing 0 DSACKs sent for old packets 0 DSACKs sent for out of order packets 0 DSACKs received 0 connections reset due to unexpected data 0 connections reset due to early user close 0 connections aborted due to timeout TCPSACKDiscard: 0 TCPDSACKIgnoredOld: 0 TCPDSACKIgnoredNoUndo: 0 TCPSackShifted: 130 TCPSackMerged: 80 TCPSackShiftFallback: 27
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:
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 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 16384 87380 1 1 10.00 47.40 16384 87380
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).