Comment mesurer les performances du réseau (procédure de test de protocole de réseau)

Tout d'abord, un peu à l'arrière-plan. Il ya beaucoup de différentes comparaisons de distribution des systèmes de contrôle de version (DVCS) qui comparent la taille de référentiel, ou de la référence de vitesse des opérations. Je n'ai trouvé aucun qui aurait indice de référence les performances du réseau de différents DVCS, et les différents protocoles utilisés... à côté de la mesure de la vitesse des opérations (commandes) mettant en réseau comme 'clone', 'pull'/'fetch' ou de 'push'.

Je voudrais savoir alors comment voulez-vous faire une telle comparaison; comment mesurer la performance du réseau d'une application, ou la façon de référence du protocole réseau. J'imagine ici, entre autres, la mesure de la dépendance de la performance de la bande passante du réseau et le temps de latence (ping) de réseau; certains protocoles sacrifice de la latence dans la forme de plus d'aller-retour d'échanges (de négociation) pour envoyer minimale requise finale de "pack".

Je préfère les solutions impliquant un seul ordinateur, si possible. J'aimerais voir des solutions open source, travail sur Linux. Mais je souhaite également la bienvenue plus de réponses génériques.

Préféré OS: Linux
Langues préférées: C, Perl, shell script

Mesures possibles:

  • nombre total d'octets transférés à partir du serveur vers le client et du serveur vers le client en une seule séance, ce qui peut également être utilisé pour mesurer l'overhead du protocole (bande passante)
  • nombre d'aller-retours (connexions) dans une transaction (temps de latence)
  • la dépendance de la vitesse de fonctionnement du réseau (temps qu'il faut pour cloner/pull/push) de la bande passante réseau et de la latence du réseau (ping)

La façon de faire de telles mesures (tels points de référence)?

Ajouté 02-06-2009:
Un simple indice de référence (mesure) serait une version réseau de time de commande, c'est à dire la commande exécuter serait me donner le nombre d'octets transférés, et le nombre d'allers-retours /connexions réseau lors de l'exécution d'une commande donnée.

Ajouté 09-06-2009:
Exemple imaginaire de la sortie pour l'a mentionné ci-dessus la solution de la version réseau de time commande pourrait ressembler à la suivante:

$ ntime git clone -q git://git.example.com/repo.git
...
bytes sent: nnn (nn kiB), bytes received: nnn (nn kiB), avg: nn.nn KB/s
nn reads, nn writes

Noter que c'est seulement un exemple de sortie, détaillant la nature des informations que l'on peut vouloir obtenir.

Ajouté 09-06-2009:
Il ressemble à ce que je veux, peuvent être réalisés à l'aide alors dummynet, outil (à l'origine) pour tester les protocoles de mise en réseau...

Demandez-vous, comment obtenir les données nécessaires afin d'arriver à de telles références pour l'arbitraire d'un réseau de programme?
Oui, j'aimerais avoir au minimum obtenir le nombre total d'octets transférés et peut-être le nombre de changements de lire à écrire pour une commande donnée, quelque chose comme le temps / temps pour le CPU et la mémoire, et de SystemTap iotimes pour les I/O.
Je pense que pour vraiment répondre à votre question, vous avez, idéalement, devrait nous en dire plus sur votre choix de plate-forme/OS, ainsi que votre langage de programmation préféré. Aussi, une liste détaillée de mesures qui vous intéressent, qui nous permettra de savoir quelle est l'approche la plus faisable.
Ajouté. Préféré le système d'exploitation est Linux, langues préférées comprennent (sans ordre) C, Perl, shell script, mais peut être en Python ou en Java ou autre langage de programmation.

OriginalL'auteur Jakub Narębski | 2009-05-20

  1. 15

    Si je suis à vous comprendre correctement, vous êtes intéressé par quelque chose comme Linux 'strace' (Introduction) pour le réseau-système spécifique d'appels?

    Éventuellement une combinaison d'un générateur de profils et d'un débogueur, pour les applications réseau (c'est à dire 'ntrace'), fournissant une analyse détaillée des différents facultatif mesures?

    Sous Linux, le strace utilitaire est en grande partie basée sur la fonctionnalité est fournie par le noyau Linux, à savoir la ptrace (suivi des processus) API:

    Utilisant ptrace, il devrait être possible d'obtenir la plupart des données qui vous intéressent.

    Sur Windows, vous aurez probablement envie de regarder dans détours pour intercepter/rediriger les appels Winsock API pour l'inspection/fins d'analyse comparative.

    Si vous n'avez pas vraiment besoin de cette information à bas niveau, vous pouvez probablement aussi directement utiliser strace (sur linux) et utilisez-la uniquement pour retracer certains appels système, par exemple, considérons la ligne suivante ce qui ne ferait que les appels de suivi pour ouvrir l'syscall (à l'Aide de la-o FICHIER de paramètre, vous pouvez rediriger toutes les sorties vers un fichier de sortie):

    strace -e trace=open -o results.log

    Par le passage d'un supplémentaire drapeau-v pour strace, vous pouvez augmenter son niveau de verbosité pour obtenir des informations supplémentaires (lorsque l'on travaille avec des Mec comme git qui sont composé de nombreux petits utilitaires d'environnement et outils autonomes, vous voudrez aussi de regarder dans l'aide de l'option-f afin de suivre fourche processus).

    Donc, ce qui serait susceptible de vous intéresser, est de tous les appels qui sont liées à sockets, à savoir:

    • accepter
    • lier
    • connecter
    • getpeername
    • getsockname
    • getsockopt
    • écouter
    • recv
    • recvfrom
    • envoyer
    • sendto
    • setsockopt
    • arrêt
    • socket
    • par socketpair

    (au début, vous aurez probablement envie de regarder en traitant de l'envoyer.../recv... des appels, tout de même)

    Pour simplifier, vous pouvez également utiliser le "réseau" comme paramètre à la trace, qui permettra de suivre tous liés au réseau d'appels:

    -e trace=réseau: retrouver l'ensemble du réseau du système des appels.

    Donc, un strace invocation pourrait ressembler à ceci:

    strace -v -e trace=accept,bind,connect,getpeername,getsockname,getsockopt,listen,recv,recvfrom,send,sendto setsockopt,shutdown,socket,socketpair -o results.log -f git pull

    Lorsque le programme est terminé en cours d'exécution, vous aurez alors principalement voulez examinez le fichier journal pour évaluer les données, ce qui peut ensuite être facilement réalisé en utilisant des expressions régulières.

    Par exemple, lors de l'exécution de la suivante dans un shell linux:
    strace -v -o wget.log -e trace=connect,recv,recvfrom,send,sendto wget http://www.google.com

    Le fichier journal contient des messages comme ceux-ci:

    • recv(3, "HTTP/1.0 302 Found\r\nLocation: htt"..., 511, MSG_PEEK) = 511
    • sendto(4, "\24\0\0\0\26\0\1\3^\206*J\0\0\0\0\0\0\0\0"..., 20, 0, {sa_family=AF_NETLINK, pid=0, les groupes=00000000}, 12) = 20

    En regardant les pages de man pour ces deux appels système, il est évident que 511 et, respectivement, de 20 sont le nombre d'octets transférés. Si vous avez besoin d'calendrier détaillé d'informations, vous pouvez passer l'option-T pour strace:

    -T-imprimer temps passé dans chaque syscall

    En outre, vous pouvez obtenir des statistiques par passage de l'indicateur-c:

    -c: temps de Comptage, les appels et les erreurs pour chaque système d'appel et rapport un résumé du programme
    à la sortie. Sur Linux, il tente de montrer l'heure du système (CPU temps passé à exécuter dans le noyau)
    indépendants de temps horloge murale. Si -c est utilisée avec l'option-f ou -F (ci-dessous), seuls les granulats
    les totaux pour tous les tracés procédés sont conservés.

    Si vous avez également besoin d'examiner les données réelles transformés, vous voudrez peut-être chercher dans la lecture/écriture des prescripteurs:

    -e=set: Effectuer un plein format hexadécimal et ASCII dump de toutes les données lues à partir du fichier
    descripteurs figurant dans le jeu spécifié. Par exemple, pour voir toutes les entrées de l'activité sur le fichier
    les descripteurs de 3 et 5 utilisez -e=3,5. Notez que ceci est indépendant de la normale
    le traçage de la lecture(2) de l'appel système qui est contrôlé par l'option-e trace=lire.
    -e écrire=set: Effectuer un plein format hexadécimal et ASCII dump de toutes les données écrites sur le fichier
    descripteurs figurant dans le jeu spécifié. Par exemple, pour voir toute l'activité de sortie sur fichier
    les descripteurs de 3 et 5 utilisez -e écrire=3,5. Notez que ceci est indépendant de la normale
    traçage de l'écriture(2) de l'appel système qui est contrôlé par l'option-e trace=écrire.

    Vous pouvez également personnaliser la longueur maximale des chaînes:

    -s strsize: Spécifiez la taille maximale de la chaîne d'impression (la valeur par défaut est de 32). Notez que
    les noms de fichiers ne sont pas considérés comme des chaînes et sont toujours imprimées en

    Ou des chaînes sous-évaluées comme hex:

    -xx: Imprimer toutes les chaînes de caractères en hexadécimal format de chaîne de caractères.

    Donc, à l'aide de strace pour beaucoup de ce, semble être une bonne approche hybride, parce qu'il est très facile à faire, mais il reste encore une bonne quantité de faible niveau d'informations disponibles, si vous trouvez que vous avez besoin de plus faible niveau d'informations, vous pouvez envisager d'étendre strace au lieu de dépôt correspondant demandes de fonctionnalités avec la strace projet sur sourceforge.

    Cependant, en pensant un peu plus, un de moins impliqués et plus de la plate-forme agnostique de la mise en œuvre assez simple réseau de trafic de référence, serait d'utiliser une certaine forme de couche intermédiaire entre le client et le serveur: un serveur qui est en gros de mesure, d'analyse et de rediriger le trafic vers le serveur réel.

    Un peu comme un serveur proxy (e.g CHAUSSETTES), de sorte que tout le trafic est passé à travers votre analyseur, qui à leur tour peuvent accumuler des statistiques et d'autres mesures.

    Une version de base de quelque chose comme cela pourrait être facilement mis en place en utilisant netcat et certains scripts shell, les versions plus complexes peuvent toutefois bénéficier de l'aide de perl ou python.

    Pour un python de la mise en œuvre d'un serveur SOCKS, vous voudrez peut-être chercher dans pysocks.

    Aussi, il y a bien sûr tordu pour python:

    Torsadée est un événement piloté par les réseaux moteur écrit en Python
    et sous licence MIT.

    Si vous avez besoin d'avoir plus d'information à bas niveau, vous aurez probablement vraiment besoin de se pencher sur l'interception des appels système.

    Si vous avez besoin spécifique à un protocole données d'efficacité, vous voudrez peut-être regarder dans tcpdump.

    OriginalL'auteur none

  2. 5

    Possible réponse serait d'utiliser SystemTap. Parmi les exemples de scripts, il est nettop qui affiche quelques informations de connexion au réseau dans le "top"-comme la mode, et il y a iotime script qui affiche I/O de l'information dans le formulaire requis.

    OriginalL'auteur Jakub Narębski