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).