httperf - En ligne dans le Cloud

PROGRAMME:

Nom

httperf - Outil de mesure des performances HTTP

SYNOPSIS

httperf [--add-en-tête S] [--longueur de rafale N] [--client I/N] [--fermer-avec-réinitialisation]
[-d|--déboguer N] [--échec-statut N] [-h|--Aidez-moi] [--porc] [--version-http S] [--maximum-
liens N] [--max-appels canalisés N] [--méthode S] [--no-host-hdr] [--num-appels N] [--num-
arnaque N] [--période [d|u|e]T1[,T2]] [--Port N] [--print-réponse [entête|corps]] [--imprimer-
demandez [entête|corps]] [--taux X] [--recv-buffer N] [--réessayer en cas d'échec] [--send-buffer N]
[--serveur S] [--nom du serveur S] [--session-cookie] [--ssl] [--chiffres-ssl L] [--ssl-non-
réutiliser] [--timeout de réflexion X] [--temps libre X] [--uri S] [-v|--verbeux] [-V|--version] [--wlog
y|n,F] [--wsess N,N,X] [--wsesslog N,X,F] [--wset N,X]

DESCRIPTION

httperf est un outil pour mesurer les performances d'un serveur Web. Il parle le protocole HTTP à la fois en
ses variantes HTTP/1.0 et HTTP/1.1 et offre une variété de générateurs de charge de travail. Tandis que
en cours d'exécution, il garde une trace d'un certain nombre de mesures de performance qui sont résumées sous la forme
de statistiques qui sont imprimées à la fin d'un test. L'opération la plus basique de
httperf est de générer un nombre fixe de requêtes HTTP GET et de mesurer le nombre de réponses
(réponses) sont revenus du serveur et à quelle vitesse les réponses sont arrivées.

IMPORTANT: Pour obtenir des résultats corrects, il est nécessaire d'exécuter au plus un httperf processus
par poste client. En outre, il devrait y avoir aussi peu de processus d'arrière-plan que possible à la fois sur
les machines client et serveur.

EXEMPLES

httperf --hog --serveur www
Cette commande provoque httperf pour créer une connexion à l'hébergeur www, envoyez une demande de
le document racine (http://www/), recevez la réponse, fermez la connexion, puis
imprimer des statistiques de performances.

httperf --hog --server www --num-conns 100 --ra 10 --timeout 5
Comme ci-dessus, sauf qu'un total de 100 connexions sont créées et que les connexions
sont créés à un taux fixe de 10 par seconde. Notez que l'option ``--rate'' a été
abrégé en ``--ra''.

httperf --hog --server=www --wsess=10,5,2 --rate 1 --timeout 5
Causes httperf générer un total de 10 séances à raison de 1 séance par
seconde. Chaque session se compose de 5 appels espacés de 2 secondes.

httperf --hog --server=www --wsess=10,5,2 --rate=1 --timeout=5 --ssl
Comme ci-dessus, sauf que httperf contacte le serveur www via SSL au port 443 (le
port par défaut pour les connexions SSL).

httperf --hog --server www --wsess=10,5,2 --rate=1 --timeout=5 --ssl
--ssl-ciphers=EXP-RC4-MD5:EXP-RC2-CBC-MD5 --ssl-no-reuse --http-version=1.0
Comme ci-dessus, sauf que httperf informera le serveur qu'il ne peut sélectionner que
deux suites de chiffrement (EXP-RC4-MD5 ou EXP-RC2-CBC-MD5) ; par ailleurs, httperf utilisera
HTTP version 1.0 qui nécessite une nouvelle connexion TCP pour chaque requête. Aussi, SSL
les identifiants de session ne sont pas réutilisés, donc tout le processus d'établissement de la connexion SSL
(connu sous le nom d'établissement de liaison SSL) se produit pour chaque connexion.

OPTIONS

Le fonctionnement de httperf peut être contrôlé par un certain nombre d'options. L'outil prend en charge
les noms d'options à la fois courts (un caractère) et longs (de longueur arbitraire). Les options courtes sont
préfixé par un seul tiret (-), options longues avec un double tiret (--). Plusieurs
les options courtes peuvent être regroupées (par exemple, ``-vV'' équivaut à ``-v -V'') et longue
les options peuvent être abrégées tant qu'elles restent uniques. Les paramètres des options peuvent être
spécifié soit en faisant suivre le nom long de l'option d'un signe égal et du paramètre
valeur (par exemple, --rafale=10) ou en séparant le nom et la valeur de l'option par des espaces (par exemple,
--éclater 10).

--ajouter-en-tête=S
Spécifie d'inclure la chaîne S comme en-tête de requête supplémentaire. Il est nécessaire de
spécifier explicitement la séquence de fin de retour chariot/saut de ligne. Cela peut être
fait en utilisant la séquence d'échappement ``\n''. Cela permet d'inclure
plusieurs en-têtes de requête. Par exemple, ``--add-header "Referer : foo\nAuth :
secret\n"'' ajouterait deux en-têtes de requête (``Referer'' et ``Auth'') à chacun
demander. Les autres séquences d'échappement prises en charge sont ``\r'' (retour chariot), ``\a''
(saut de ligne), ``\\'' (barre oblique inverse) et ``\N'' où N est le code du caractère à être
inséré (en octal).

--rafale-longueur=N
Spécifie la longueur des rafales. Chaque rafale se compose de N appels au serveur. Les
la signification exacte de ce paramètre dépend du générateur de charge de travail. Pour régulier
charges de travail orientées requêtes, voir la description de l'option --wsess.

--no-host-hdr
Spécifie que l'en-tête « Host : » ne doit pas être inclus lors de l'émission d'un HTTP
demande.

--num-appels.
Pour les charges de travail orientées session, voir la description de l'option --wsess.

--client=I/N
Spécifie que la machine httperf est en cours d'exécution sur son client I sur un total de N
clients. I doit être compris entre 0 et N-1. Certains des générateurs de charge de travail
(par exemple, --wset) utiliser l'identité du client comme valeur de biais pour s'assurer que tous
les clients génèrent des charges de travail parfaitement identiques. Lors de l'exécution d'un test qui
implique plusieurs machines clientes, c'est généralement une bonne idée de spécifier cette
option.

--fermer-avec-réinitialisation
Demande que httperf ferme les connexions TCP en envoyant un RESET au lieu d'aller
via la poignée de main d'arrêt de la connexion TCP normale. L'activation de cette option peut
avoir des effets néfastes tels que la corruption de données, des blocs de contrôle TCP bloqués ou une erreur
résultats. Pour cette raison, l'option ne doit être utilisée que si absolument
nécessaire et même dans ce cas, il ne devrait pas être utilisé à moins que ses implications ne soient pleinement
compris.

-d=N

--debug=N
Définir le niveau de débogage sur N. Plus grandes valeurs de N se traduira par plus de sortie.

--failure-statut=N
Spécifie qu'un code d'état de réponse HTTP de N doit être traité comme un échec
(c'est-à-dire traité comme si la demande avait expiré, par exemple). Par exemple, avec
``--failure-status=504'' réponses avec un statut HTTP de `` 504 Gateway Time-out''
seraient considérés comme des échecs. Avertissement : cette option est actuellement prise en charge pour
charges de travail de session uniquement (voir le --wsess et --wsesslog option).

-h

--Aidez-moi Imprime un résumé des options disponibles et de leurs paramètres.

--porc Cette option demande d'utiliser autant de ports TCP que nécessaire. Sans cela
option, httperf est généralement limité à l'utilisation de ports éphémères (de l'ordre de
1024 à 5000). Cette plage de ports limitée peut rapidement devenir un goulot d'étranglement, il est donc
généralement une bonne idée de spécifier cette option pour des tests sérieux. Aussi, ce
L'option doit être spécifiée lors de la mesure des serveurs NT car elle évite un TCP
incompatibilité entre les machines NT et UNIX.

--http-version=S
Spécifie la chaîne de version qui doit être incluse dans les requêtes envoyées au
serveur. Par défaut, la chaîne de version ``1.1'' est utilisée. Cette option peut être définie sur
``1.0'' pour forcer la génération de requêtes HTTP/1.0. Définir cette option sur n'importe quel
une valeur autre que ``1.0'' ou ``1.1'' peut entraîner un comportement indéfini.

--max-connexions=N
Spécifie qu'au plus N des connexions sont ouvertes pour chaque session. Cette option est
significatif en conjonction avec les options --wsess et --wsesslog seulement.

--max-piped-calls=N
Spécifie qu'au plus N des appels en pipeline sont émis sur chaque connexion. Cette
l'option est significative en conjonction avec les options --wsess et --wsesslog seulement.

--méthode=S
Spécifie la méthode qui doit être utilisée lors de l'émission d'une requête HTTP. Si ce
option n'est pas spécifiée, la méthode GET est utilisée. La méthode S peut être arbitraire
chaîne mais est généralement l'un des éléments GET, HEAD, PUT, POST, etc.

--num-appels=N
Cette option n'a de sens que pour les charges de travail orientées requête. Il précise le
nombre total d'appels à émettre sur chaque connexion avant de la fermer. Si N is
supérieur à 1, le serveur doit prendre en charge les connexions persistantes. La valeur par défaut
pour cette option est 1. Si --longueur de rafale est fixé à B, puis le N des appels sont émis
en rafales de B appels en pipeline chacun. Ainsi, le nombre total de ces rafales sera
N / B (par connexion).

--num-conns=N
Cette option n'a de sens que pour les charges de travail orientées requête. Il précise le
nombre total de connexions à créer. A chaque connexion, les appels sont émis comme
spécifié par les options --num-appels et --longueur de rafale. Un test s'arrête dès que le N
les connexions sont terminées ou ont échoué. Une connexion est considérée comme ayant
a échoué si une activité sur la connexion ne progresse pas pendant plus
que le temps spécifié par les options de délai d'attente --temps libre et --timeout de réflexionL’
la valeur par défaut de cette option est 1.

--période=[J]T1[,T2]
Spécifie l'intervalle de temps entre la création de connexions ou de sessions.
Les connexions sont créées par défaut, les sessions si option --wsess or --wsesslog a
été spécifié. Cette connexion/session ``temps d'interarrivée'' peut alternativement être
spécifié par le --taux option, bien que plus de flexibilité soit disponible avec
--période. Le D paramètre spécifie la distribution du temps entre les arrivées. Si
omis ou défini sur ``d'', une période déterministe (c'est-à-dire fixe) est utilisée comme spécifié
par paramètre T1 en unités de secondes. Si D est défini sur ``e'', une exponentielle (c'est-à-dire,
Poisson) est utilisée avec un temps moyen entre les arrivées de T1. Enfin, si D
est défini sur ``u'', une distribution uniforme sur l'intervalle [T1,T2) est utilisé pour le
Temps interarrival. Dans tous les cas, une période de 0 entraîne des connexions ou des sessions
étant généré de manière séquentielle (une nouvelle connexion/session est initiée dès que le
le précédent se termine). La valeur par défaut de cette option est 0. Notez que
en précisant, par exemple, --taux=5 équivaut à spécifier --période=d0.2 or
--période=0.2. En précisant --période=u1,3, les temps d'interarrivée seront aléatoirement
choisi dans l'intervalle entre 1 et 3 secondes. La séquence spécifique de
les temps d'interarrivée (pseudo-)aléatoires sont identiques d'un httperf courir vers un autre comme
tant que les valeurs de --période et --client les options sont identiques.

--port=N
Cette option spécifie le numéro de port N sur lequel le serveur Web est à l'écoute
requêtes HTTP. Par défaut, httperf utilise le numéro de port 80.

--print-réponse[=[entête|corps]]
Demande l'impression des en-têtes, du corps et du résumé de la réponse. La sortie est
dirigé vers la sortie standard. Les lignes d'en-tête de réponse sont préfixées par "RH", le corps de la réponse
les lignes sont préfixées par « RB » et le résumé de la taille de la réponse est préfixé par « RS ». Les
préfixe est suivi d'un numéro de série qui identifie de manière unique l'appel que le
la ligne de réponse est pour et un caractère deux-points (":") qui marque le début de la
ligne de réponse réelle. Pour imprimer uniquement les en-têtes de réponse, passez l'argument entête à cette
option. Pour imprimer uniquement le corps de la réponse, passez l'argument corps à cette option.

--print-demande[=[entête|corps]]
Demande l'impression des en-têtes de la demande, du corps (s'il y en a un) et
sommaire. La sortie est dirigée vers la sortie standard. Les lignes d'en-tête de demande sont
préfixé par "SH", les lignes du corps de la requête sont préfixées par "SB", et le résumé de la requête
est préfixé par "SS". Le préfixe est suivi du numéro de série de l'appel et d'un
deux-points (":") caractère qui marque le début de la ligne de réponse réelle. Imprimer
uniquement les en-têtes de requête, passer l'argument entête à cette option. Pour imprimer uniquement le
corps de la requête, passer l'argument corps à cette option.

--taux=X
Spécifie le débit fixe auquel les connexions ou les sessions sont créées. Connexions
sont créés par défaut, les sessions si option --wsess or --wsesslog a été
spécifié. Dans les deux cas, un taux de 0 entraîne des connexions ou des sessions
généré séquentiellement (une nouvelle session/connexion est initiée dès que le
le précédent se termine). La valeur par défaut de cette option est 0.

--recv-buffer=N
Spécifie la taille maximale des tampons de réception de socket utilisés pour recevoir HTTP
réponses. Par défaut, la limite est de 16 Ko. Une valeur plus petite peut aider la mémoire-
clients contraints alors qu'une valeur plus importante peut être nécessaire lors de la communication avec
un serveur via une connexion à large bande passante et à latence élevée.

--réessayer en cas d'échec
Cette option n'a de sens que pour les charges de travail de session (voir le --wsess et
--wsesslog option). Si spécifié, un appel qui entraîne une réponse d'échec (comme
défini par le --échec-statut option) est réessayé immédiatement au lieu de provoquer
la session échoue.

--send-buffer=N
Spécifie la taille maximale des tampons d'envoi de socket utilisés pour envoyer des requêtes HTTP.
Par défaut, la limite est de 4 Ko. Une valeur plus petite peut aider les clients à mémoire limitée
alors qu'une valeur plus élevée peut être nécessaire lors de la génération de requêtes volumineuses vers un serveur
connecté via une connexion à large bande passante et à latence élevée.

--serveur=S
Spécifie le nom d'hôte IP du serveur. Par défaut, le nom d'hôte ``localhost'' est
utilisé. Cette option doit toujours être spécifiée car ce n'est généralement pas une bonne idée de
exécuter le client et le serveur sur la même machine.

--nom-serveur=S
Spécifie le nom de serveur (par défaut) qui apparaît dans l'en-tête « Host : » de chaque
demande envoyée par httperf. Sans cette option, le nom d'hôte (ou l'adresse IP)
spécifié par option --serveur est utilisé à la place.

--session-cookie
Lorsque cette option est activée, la gestion des cookies est activée par session.
Cela signifie que si une réponse à une demande générée par session X
contient un cookie, puis toutes les futures requêtes envoyées par session X comprendra ce
biscuit aussi. À l'heure actuelle, le gestionnaire de cookies dans httperf prend en charge un seul cookie
par session. Si un deuxième cookie est reçu, le nouveau cookie écrase le
existant et un message d'avertissement est affiché si ``--debug 1'' est activé.

--ssl Spécifie que toutes les communications entre httperf et le serveur doit utiliser le
Protocole SSL (Secure Sockets Layer). Cette option n'est disponible que si httperf était
compilé avec le support SSL activé.

--ssl-cipher=L
Cette option n'a de sens que si SSL est utilisé (voir --ssl option). Cette option
précise la liste L de suites de chiffrement qui httperf peut utiliser dans la négociation d'un
connexion avec le serveur. Si la liste contient plus d'une suite de chiffrement, le
les chiffres doivent être séparés par deux points. Si le serveur n'accepte aucun des
suites de chiffrement répertoriées, l'établissement de la connexion échouera et httperf va quitter
immédiatement. Si cette option n'est pas spécifiée lorsque le --ssl l'option est présente alors
httperf utilisera toutes les suites de chiffrement SSLv3 fournies par le SSL sous-jacent
bibliothèque.

--ssl-pas de réutilisation
Cette option n'a de sens que si SSL et des sessions sont en cours d'utilisation (voir --ssl, --wsess,
--wsesslog). Lorsqu'une connexion SSL est établie, le client reçoit une session
identifiant (identifiant de session) du serveur. Lors des connexions SSL suivantes, le client
réutilise normalement cet identifiant de session afin d'éviter les dépenses liées à la répétition du
(lent) établissement de liaison SSL pour établir une nouvelle session SSL et obtenir un autre identifiant de session
(même si le client tente de réutiliser un identifiant de session, le serveur peut forcer le
client de renégocier une session). Par défaut httperf réutilise l'identifiant de session à travers
toutes les connexions d'une session. Si la --ssl-pas de réutilisation l'option est en vigueur, alors
httperf ne réutilisera pas l'identifiant de session et l'ensemble de la négociation SSL sera
effectuée pour chaque nouvelle connexion dans une session.

--think-timeout=X
Spécifie le temps maximum dont le serveur peut avoir besoin pour lancer l'envoi de la réponse
pour une demande donnée. Notez que cette valeur de délai d'attente est ajoutée au délai d'attente normal
valeur (voir option --temps libre). Lors de l'accès à du contenu Web statique, il n'est généralement pas
nécessaire de spécifier cette option. Cependant, lors de l'exécution de tests avec des
scripts CGI, il peut être nécessaire d'utiliser cette option pour permettre une plus grande réponse-
fois. La valeur par défaut de cette option est de zéro seconde, ce qui signifie que le serveur
doit être capable de répondre dans le délai d'attente normal.

--timeout=X
Spécifie la durée X qui httperf est prêt à attendre un serveur
réaction. Le délai d'attente est spécifié en secondes et peut être un nombre fractionnaire
(par exemple, --temps libre 3.5). Cette valeur de délai d'attente est utilisée lors de l'établissement d'un TCP
connexion, lors de l'envoi d'une demande, lors de l'attente d'une réponse et lors de la réception d'un
répondre. Si, au cours de l'une de ces activités, une demande ne progresse pas
dans le temps imparti, httperf considère que la demande est décédée, clôt le
connexion ou session associée et augmente la client-temps nombre d'erreurs. Les
la valeur réelle du délai d'attente utilisée lors de l'attente d'une réponse est la somme de ce délai d'attente et
le temps de réflexion (voir option --timeout de réflexion). Par défaut, la valeur du délai d'attente est
infini.

--uri=S
Spécifie que l'URI S doit être accessible sur le serveur. Pour une partie de la charge de travail
générateurs (par exemple, --wset), cette option spécifie le préfixe des URI à
accédé.

-v

--verbeux
Puts httperf en mode verbeux. Dans ce mode, des sorties supplémentaires telles que le
des échantillons de taux de réponse individuels et un histogramme de durée de vie de connexion sont imprimés.

-V

--version
Imprime la version de httperf.

--wlog=B,F
Cette option peut être utilisée pour générer une séquence spécifique d'accès URI. C'est
utile pour rejouer les accès enregistrés dans un fichier journal du serveur, par exemple.
Paramètre F est le nom d'un fichier contenant la liste d'URI séparée par NUL ASCII
qui devrait être accessible. Si paramètre B est défini sur ``y'', httperf s'enroulera autour
au début du fichier lorsqu'on atteint la fin de la liste (donc la liste des URI
est consulté à plusieurs reprises). Avec B mis à ``n'', le test s'arrêtera au plus tard le
lorsque vous atteignez la fin de la liste d'URI.

--wsess=N1,N2,X
Demande la génération et la mesure de sessions au lieu de demandes individuelles.
Une session se compose d'une séquence de rafales qui sont espacées par l'utilisateur pense-
temps. Chaque rafale se compose d'un nombre fixe L d'appels au serveur (L is
spécifié par option --longueur de rafale). Les appels d'une rafale sont émis comme suit :
au début, un seul appel est émis. Une fois la réponse à ce premier appel
entièrement reçus, tous les appels restants dans la rafale sont émis simultanément. Les
les appels simultanés sont émis soit en tant qu'appels en pipeline sur un serveur persistant existant
connexion ou sous forme d'appels individuels sur des connexions séparées. Qu'il s'agisse d'un persistant
la connexion est utilisée dépend de si le serveur répond au premier appel avec un
réponse qui inclut une ligne d'en-tête ``Connection: close''. Si une telle ligne est
présent, des connexions séparées sont utilisées.

L'option spécifie les paramètres suivants : N1 est le nombre total de séances
générer, N2 est le nombre d'appels par session, et X est le temps de réflexion de l'utilisateur
(en secondes) qui sépare les rafales d'appels consécutives. Par exemple, les options
``--wsess=100,50,10 --burst-len 5'' donnerait 100 sessions avec un total de 50
appelle chacun. Étant donné que chaque rafale a une durée de 5 appels, un total de 10 rafales d'appels
serait généré par session. Le temps de réflexion de l'utilisateur entre les rafales d'appels serait
10 secondes. Notez que le temps de réflexion de l'utilisateur X désigne le temps entre la réception du
dernière réponse de la salve d'appel précédente et l'envoi de la première requête du
prochaine rafale.

Un test comportant des sessions se termine dès que le nombre demandé N1 de sessions
ont échoué ou terminé. Une session est considérée comme ayant échoué le cas échéant
l'opération dans une session prend plus de temps que les délais spécifiés par les options
--temps libre et --timeout de réflexion. De plus, une session échoue également si le serveur
renvoie une réponse avec un code d'état correspondant à celui spécifié par option --échec-
statuts.

--wsesslog=N,X,F
Cela spécifie un générateur de charge de travail de session similaire à --wsess (merci de lire ça
description d'abord). Avec --wsesslog cependant, de nombreux aspects des sessions utilisateur,
y compris le nombre et la séquence des URI, la méthode de demande, le temps de réflexion et le burst-
paramètres de longueur, peuvent être spécifiés dans un fichier d'entrée F. Deux autres paramètres sont
retenu de --wss, à savoir N, le nombre de sessions à initier, et X, le
temps de réflexion de l'utilisateur de rafale à rafale (notez qu'il s'agit du temps par défaut puisque le
fichier d'entrée F peut également spécifier le temps de réflexion de l'utilisateur par rafale. Un petit
l'exemple de fichier d'entrée peut afficher plus facilement les paramètres réglables :

# Les lignes de commentaires commencent par un ``#'' comme premier
# personnage. Lignes avec seulement des espaces blancs délimités
# sessions (plusieurs lignes vides ne génèrent pas
# sessions ``nulles''). Toutes les autres lignes spécifient un
# uri-sequence (1 uri par ligne). Si le premier
# caractère de la ligne est un espace (par exemple espace
# ou tab), l'uri est considérée comme faisant partie d'un
# burst qui est envoyé après le précédent
# uri sans rafale.

# définition de la session 1 (ceci est un commentaire)
/foo.html pense=2.0
/pict1.gif
/pict2.gif
/foo2.html method=POST contents='Post data'
/pict3.gif
/pict4.gif

# définition de la session 2
/foo3.html method=POST contents="Multiline\ndata"
/foo4.html méthode=TÊTE

La description ci-dessus spécifie 2 sessions. La première session commencera par un
demande de /foo.html. Lorsque la réponse /foo.html revient, une rafale de 2
les demandes suivront (/pict1.gif et /pict2.gif). Quand la dernière de ces réponses
est reçu, un temps de réflexion utilisateur de deux secondes est inséré avant la prochaine demande de
/foo2.html est émis. Cette requête est envoyée sous forme de POST. Les données affichées peuvent être
entre guillemets simples ou doubles. Des nouvelles lignes peuvent apparaître dans les données publiées
comme ``\n'' ou comme ``\ ''. La réponse /foo2.html est suivie d'une rafale
demande de /pict3.gif et /pict4.gif, qui conclut cette session. La deuxième
session est démarrée quelque temps après la première, comme spécifié par le --taux or
--période options.

La deuxième session consiste en 2 requêtes séparées par le temps de réflexion par défaut de l'utilisateur
comme spécifié par le X paramètre de la --wsesslog option. Si la N paramètre de
--wsesslog est supérieur au nombre de sessions défini dans le fichier d'entrée F, puis le
les sessions définies sont utilisées à plusieurs reprises jusqu'à ce que N sessions ont été créées (c.-à-d.
sessions définies sont utilisées de manière circulaire).

Il faut éviter d'utiliser --wsesslog en conjonction avec d'autres httperf des options qui
contrôler également le comportement de la session et les URI de la charge de travail, à savoir --longueur de rafale, --wss,
--wlog, et --wset.

--wset=N,X
Cette option peut être utilisée pour parcourir une liste d'URI à un débit donné. Paramètre
N spécifie le nombre d'URI distincts qui doivent être générés et X précise
le taux d'accès aux nouveaux URI. Un taux de 0.25 signifierait que la même
L'URI serait accédé quatre fois de suite avant de passer à l'URI suivant. Cette
type de modèle d'accès est utile pour générer une charge de travail qui induit une
quantité prévisible de trafic dans le sous-système d'E/S de disque du serveur (en supposant N
et les fichiers accédés sont suffisamment volumineux pour dépasser le cache tampon du serveur). Les
Les URI générés sont de la forme préfixe/chemin.html, où préfixe est le préfixe d'URI
spécifié par option --wset et chemin est généré comme suit : pour le i-ième fichier dans
l'ensemble de travail, notez i en décimal, préfixant le nombre avec autant de zéros
si nécessaire pour obtenir une chaîne qui a autant de chiffres que N-1. Ensuite, insérez une barre oblique
caractère entre chaque chiffre. Par exemple, le 103e fichier d'un jeu de travail
composé de 1024 fichiers se traduirait par un chemin de ``0 / 1 / 0 / 3''. Ainsi, si l'URI-
le préfixe est /wset1024, alors l'URI auquel on accède serait /wset1024/0/1/0/3.html.
En d'autres termes, les fichiers sur le serveur doivent être organisés sous forme d'arborescence 10aire.

SORTIE

Cette section décrit la sortie des statistiques à la fin de chaque exécution de test. Les bases
les informations ci-dessous sont imprimées indépendamment du générateur de charge de travail sélectionné.

Total : connexions 30000 requêtes 29997 réponses 29997 durée de test 299.992 s

La connexion taux: 100.0 conn/s (10.0 ms/conn, <=14 connexions simultanées)
La connexion fois [Mme]: min 1.4 moy 3.0 max 163.4 médiane 1.5 stddev 7.3
La connexion fois [Mme]: connecter 0.6
La connexion longueur [réponses/conn] : 1.000

Demande taux: 100.0 req/s (10.0 ms/req)
Demande Taille [B] : 75.0

Répondre taux [réponses/s] : min 98.8 moy 100.0 max 101.2 stddev 0.3 (60 échantillons)
Répondre fois [Mme]: réponse 2.4 transfert 0.0
Répondre Taille [B] : en-tête 242.0 contenu 1010.0 pied de page 0.0 (total 1252.0)
Répondre statut: 1xx=0 2xx=29997 3xx=0 4xx=0 5xx=0

Processeur fois [s] : utilisateur 94.31 système 205.26 (utilisateur 31.4 % système 68.4 % total 99.9 %)
Net I / O: 129.6 Ko/s (1.1 x 10^6 bits/s)

Les erreurs: total 3 client-timo 0 socket-timo 0 connrefusé 3 connreset 0
Les erreurs: fd-unavail 0 addrunavail 0 ftab-full 0 autre 0

Il existe six groupes de statistiques : résultats globaux (« Total »), liés à la connexion
résultats (``Connexion''), résultats relatifs à l'émission de requêtes HTTP (``Requête''),
résultats relatifs aux réponses reçues du serveur (``Reply''), divers
les résultats relatifs à l'utilisation du CPU (``CPU'') et du réseau (``Net I/O'') et, enfin,
notamment, un résumé des erreurs rencontrées (``Errors'').

Section totale
Cette section résume le nombre de connexions TCP initiées par httperf, Comment
le nombre de demandes qu'il a envoyées, le nombre de réponses qu'il a reçues et le nombre total de tests
la durée était. Dans l'exemple de sortie ci-dessus, 30,000 XNUMX connexions ont été créées,
29,997 29,997 demandes ont été envoyées et XNUMX XNUMX réponses ont été reçues. La durée de
le test a duré presque exactement 5 minutes (300 secondes).

Section de connexion
Cette section contient des informations relatives aux connexions TCP générées par l'outil.
Plus précisément, la ligne « Taux de connexion » indique que de nouvelles connexions ont été
initié à un taux de 100.0 connexions par seconde. Ce taux correspond à un
période de 10.0 millisecondes par connexion. Le dernier chiffre de cette ligne indique
qu'au plus 14 connexions étaient ouvertes à un moment donné.

La première ligne intitulée ``Temps de connexion'' donne des statistiques de durée de vie pour
Connexions. La durée de vie d'une connexion est le temps entre une connexion TCP est
initié et l'heure à laquelle la connexion est fermée. Une connexion est considérée
réussi s'il avait au moins un appel qui s'est terminé avec succès. Dans l'exemple
sortie, la ligne indique que la durée de vie minimale (``min'') de la connexion était de 1.4
millisecondes, la durée de vie moyenne (``avg'') était de 3.0 millisecondes, la durée maximale
(``max'') était de 163.4 millisecondes, la durée de vie médiane (``median'') était de 1.5
millisecondes, et que l'écart type des durées de vie était de 7.3
millisecondes. La durée de vie médiane est calculée sur la base d'un histogramme avec un
résolution en millisecondes et une durée de vie maximale de 100 secondes. Ainsi, la médiane est
précis à une demi-milliseconde près si au moins la moitié de la réussite
les connexions ont une durée de vie ne dépassant pas 100 secondes.

La statistique suivante dans cette section est le temps moyen qu'il a fallu pour établir un TCP
lien. Seuls les établissements de connexion TCP réussis sont comptés. Dans le
exemple, la deuxième ligne intitulée ``Heure de connexion'' montre qu'en moyenne, il
a pris 0.6 milliseconde pour établir une connexion.

La dernière ligne de cette section est intitulée ``Longueur de connexion.'' Elle donne la
nombre moyen de réponses reçues sur chaque connexion ayant reçu au moins une
réponse (c'est-à-dire que les connexions qui ont échoué avant de donner la première réponse ne sont pas
dénombré). Ce nombre peut être supérieur à 1.0 en raison de connexions persistantes.

Section de demande
La ligne intitulée ``Request rate'' donne le taux auquel les requêtes HTTP ont été émises
et la période à laquelle correspond ce taux. Dans l'exemple ci-dessus, la demande
le taux était de 100.0 demandes par seconde, ce qui correspond à 10.0 millisecondes par
demander. Tant qu'aucune connexion persistante n'est utilisée, les résultats de cette
section sont très similaires ou identiques aux résultats de la section de connexion.
Cependant, lorsque des connexions persistantes sont utilisées, plusieurs appels peuvent être effectués sur un
connexion unique, auquel cas les résultats seraient différents.

La ligne intitulée ``Request size'' donne la taille moyenne des requêtes HTTP dans
octets. Dans l'exemple ci-dessus, la taille moyenne des requêtes était de 75 octets.

Section de réponse
Pour des mesures simples, cette section est souvent la plus intéressante comme la ligne
étiqueté ``Taux de réponse'' donne diverses statistiques pour le taux de réponse. Dans l'exemple
ci-dessus, le taux de réponse minimal (« min ») était de 98.8 réponses par seconde, la moyenne
(``moy'') était de 100 réponses par seconde, et le taux maximum (``max'') était de 101.2
réponses par seconde. L'écart type était de 0.3 réponse par seconde. Le nombre
entre parenthèses montre que 60 échantillons de taux de réponse ont été acquis. À
cadeau, httperf collecte un échantillon de fréquence toutes les cinq secondes. Pour obtenir un
écart type significatif, il est recommandé d'effectuer des tests suffisamment longtemps pour
au moins trente échantillons sont obtenus. Cela correspond à une durée d'essai d'au moins
150 secondes.

La ligne intitulée ``Reply Time'' donne des informations sur le temps qu'il a fallu pour le
serveur pour répondre et combien de temps il a fallu pour recevoir la réponse. Dans l'exemple, il
a pris en moyenne 2.4 millisecondes entre l'envoi du premier octet de la requête et
réception du premier octet de la réponse. Le temps de « transférer », ou de lire, le
La réponse était trop courte pour être mesurée, elle s'affiche donc comme zéro. Le est typique quand
la réponse entière tient dans un seul segment TCP.

La ligne suivante, intitulée ``Taille de la réponse'', contient des statistiques sur la taille moyenne des
les réponses --- tous les nombres sont en octets rapportés. Plus précisément, la ligne répertorie les
longueur moyenne des en-têtes de réponse, du contenu et des pieds de page (HTTP/1.1 utilise des pieds de page pour
réaliser l'encodage de transfert ``chunked''). Pour plus de commodité, le total moyen
nombre d'octets dans les réponses est également indiqué entre parenthèses. Dans l'exemple, le
la longueur moyenne de l'en-tête (``header'') était de 242 octets, la longueur moyenne du contenu
(``content'') était de 1010 octets, et il n'y avait pas de pied de page (la longueur du ``footer'' est
zéro). La longueur totale de la réponse de 1252 octets en moyenne.

La dernière ligne de cette section est un histogramme des principaux codes d'état reçus dans
les réponses du serveur. Le code d'état principal est le chiffre « centaines » de
le code d'état HTTP complet. Dans l'exemple, toutes les 29,997 XNUMX réponses avaient un statut majeur
code de 2. Il est probable que tous les codes d'état étaient ``200 OK'' mais le
les informations dans l'histogramme ne sont pas suffisamment détaillées pour permettre de distinguer l'état
codes avec le même code majeur.

Section Divers
Cette section commence par un résumé de l'utilisation du processeur sur la machine cliente.
Dans l'exemple, la ligne intitulée ``CPU time'' montre que 94.31 secondes ont été passées
s'exécutant en mode utilisateur (``user''), 205.26 secondes ont été passées à s'exécuter dans le système
mode (``system'') et que cela correspond à 31.4% d'exécution en mode utilisateur et 68.4%
exécution du système. L'utilisation totale était de 99.9 %, ce qui est attendu étant donné que
httperf est un porc CPU. Une utilisation totale du processeur nettement inférieure à 100 % est un
signe qu'il y avait des processus concurrents qui interféraient avec le test.

La ligne ``Net I/O'' donne le débit moyen du réseau en kilo-octets par
seconde (où un kilo-octet vaut 1024 octets) et en mégabits par seconde (où un mégabit
est de 10^6 bits). Dans l'exemple, une utilisation moyenne du réseau d'environ 129.6 kilo-octets
par seconde a été soutenue. Le nombre entre parenthèses indique que cela correspond à
environ 1.1 mégabits par seconde. Cette bande passante du réseau est calculée en fonction de la
nombre d'octets envoyés et reçus sur les connexions TCP. En d'autres termes, il fait
ne pas tenir compte des en-têtes de réseau ou des retransmissions TCP qui ont pu se produire.

Section des erreurs
La dernière section contient des statistiques sur les erreurs rencontrées lors d'une
test. Dans l'exemple, les deux lignes intitulées ``Erreurs'' indiquent qu'il y a eu un
total de trois erreurs et que les trois erreurs étaient dues au refus du serveur de
accepter une connexion (``connrefused''). Une description de chaque compteur d'erreurs
suit:

client-tim: Le nombre de fois qu'une session, une connexion ou un appel a échoué en raison d'un
délai d'expiration du client (comme spécifié par le --temps libre et --timeout de réflexion).

socket-timo : Le nombre de fois qu'une connexion TCP a échoué avec un niveau socket
délai d'attente (ETIMEDOUT).

confus: Le nombre de fois qu'une tentative de connexion TCP a échoué avec un
Erreur ``connexion refusée par le serveur'' (ECONNREFUSED).

connreset : Le nombre de fois qu'une connexion TCP a échoué en raison d'un RESET du
serveur. En règle générale, un RESET est reçu lorsque le client tente d'envoyer des données à
le serveur à un moment où le serveur a déjà fermé sa fin de connexion. NT
les serveurs envoient également des RESET lorsqu'ils tentent d'établir une nouvelle connexion lorsque le
la file d'attente est pleine.

fd-unavail : Le nombre de fois que le httperf le processus n'avait plus de descripteurs de fichiers.
Chaque fois que ce nombre est différent de zéro, les résultats du test n'ont pas de sens car le
client a été surchargé (voir la section "CHOIX DES VALEURS DE TEMPS D'ATTENTE").

addrunavail : Le nombre de fois où le client n'a plus de numéros de port TCP
(EADDRNOTAVAIL). Cette erreur ne devrait jamais se produire. Si c'est le cas, les résultats devraient être
mis au rebut.

ftab-plein : Le nombre de fois où la table des descripteurs de fichiers du système est pleine. De nouveau,
cette erreur ne devrait jamais se produire. Si c'est le cas, les résultats doivent être rejetés.

autre: Nombre de fois où un autre type d'erreur s'est produit. Chaque fois que cela
compteur est différent de zéro, il est nécessaire de rechercher la cause réelle de l'erreur. À
aider à le faire, httperf imprime le code d'erreur (errno) du premier inconnu
erreurs qui se produisent lors d'un test.

Lorsque --wsess or --wsesslog est spécifié, httperf génère et mesure les sessions à la place
des appels individuels et des statistiques supplémentaires sont imprimées à la fin d'un test. Un
un exemple de sortie est illustré ci-dessous.

Session taux [sess/s] : min 0.00 en moyenne 0.59 max 2.40 stddev 0.37 (240/450)
Session: en moyenne 6.45 connexions/session
Session durée de vie [s] : 123.9
Session temps d'échec [s] : 58.5
Session longueur histogramme : 4 7 4 ... 3 3 240

La ligne intitulée « Taux de session » indique le taux minimum, moyen et maximum auquel
sessions terminées (basé sur un intervalle d'échantillonnage de 5 secondes). Il montre également la norme
écart du taux d'achèvement de la session. Les chiffres entre parenthèses indiquent combien
sessions ont réussi et combien de sessions ont été lancées. Dans l'exemple ci-dessus, le
les taux d'achèvement de session minimum, moyen et maximum étaient de 0.00, 0.59 et 2.40 sessions
par seconde, respectivement. L'écart type était de 0.37 session par seconde et 240 sur
sur 450 sessions terminées avec succès (210 ont échoué en raison d'erreurs telles que des délais d'attente).

La ligne suivante, intitulée ``Session :'' montre la durée moyenne d'une session mesurée en
Connexions. Dans l'exemple ci-dessus, une moyenne de 6.45 connexions ont été nécessaires pour
terminer une session.

La ligne intitulée ``Durée de vie de la session'' donne le temps moyen qu'il a fallu pour terminer un
séance réussie. Dans l'exemple ci-dessus, cela a pris en moyenne 123.9 secondes.

La ligne intitulée ``Session failtime'' donne le temps moyen qu'il a fallu avant qu'un
la session infructueuse a échoué. Dans l'exemple ci-dessus, il a fallu en moyenne 58.5 secondes pour un
la session échoue.

Enfin, la ligne intitulée ``Histogramme de longueur de session'' donne un histogramme du nombre de
réponses reçues à chaque session. Dans l'exemple ci-dessus, 4 sessions se sont terminées après avoir reçu
pas de réponse du tout, 7 s'est terminé après avoir reçu une réponse, et ainsi de suite (les points de suspension indiquent
comptages d'histogrammes supplémentaires qui ont été omis de ce manuel pour des raisons d'espace). Noter
que cet histogramme ne fait pas la distinction entre les sessions réussies et échouées.

CHOISIR TIMEOUT VALEURS

Depuis la machine qui httperf s'exécute sur n'a qu'un ensemble fini de ressources disponibles, il peut
ne supporte pas des charges HTTP arbitrairement élevées. Par exemple, un facteur limitant est qu'il
n'y a qu'environ 60,000 XNUMX numéros de port TCP qui peuvent être utilisés à un moment donné. Depuis le
la plupart des systèmes UNIX, il faut une minute pour qu'une connexion TCP soit complètement fermée (laissez le
TIME_WAIT), le taux maximum qu'un client peut supporter est d'au plus 1,000 XNUMX requêtes par
seconde.

Le taux soutenable réel est souvent bien inférieur à cela parce qu'avant d'être à court de
ports TCP, la machine risque de manquer de descripteurs de fichiers (un descripteur de fichier est
utilisé pour chaque connexion TCP ouverte). Par défaut, HP-UX 10.20 autorise 1,024 XNUMX fichiers ouverts
descripteurs par processus. Cela signifie que sans précautions supplémentaires, httperf pourriez
utiliser potentiellement très rapidement tous les descripteurs de fichiers disponibles, auquel cas il pourrait
pas induire de charge supplémentaire sur le serveur. Pour éviter ce problème, httperf fournit
option --temps libre pour définir un délai d'attente pour toutes les communications avec le serveur. Si le serveur
ne répond pas avant l'expiration du délai, le client considère le
session, connexion ou appel à ``mort'' ferme la connexion TCP associée, et
augmente le nombre d'erreurs ``client-timo''. La seule exception à cette règle est qu'après
envoyer une requête entière au serveur, httperf permet au serveur de prendre des
temps avant qu'il ne commence à envoyer la réponse. C'est pour accueillir les requêtes HTTP qui prennent un
long à terminer sur le serveur. Ce temps supplémentaire est appelé le ``le serveur pense
time'' et peut être spécifié par option --timeout de réflexion. Par défaut, cette réflexion supplémentaire
le temps est de zéro seconde, donc le serveur devrait toujours répondre dans le temps imparti
par option --temps libre.

Les délais d'attente permettent httperf pour supporter des charges offertes élevées même lorsque le serveur est surchargé.
Par exemple, avec un délai d'attente de 2 secondes et en supposant que 1,000 XNUMX descripteurs de fichiers sont
disponible, la charge offerte peut aller jusqu'à 500 requêtes par seconde (en pratique, le
charge soutenable est souvent légèrement inférieure à la valeur théorique). A la baisse,
les délais d'attente tronquent artificiellement la distribution de la durée de vie de la connexion. Ainsi, c'est
recommandé de choisir une valeur de délai d'attente aussi grande que possible mais suffisamment petite pour permettre
maintenir le taux proposé souhaité. Un délai d'attente aussi court qu'une seconde peut être acceptable,
mais des délais d'attente plus longs (5 à 10 secondes) sont préférables.

Il est important de garder à l'esprit que les délais d'attente ne garantissent pas qu'un client peut
charge offerte particulière --- il existe de nombreux autres goulots d'étranglement potentiels des ressources. Pour
Par exemple, dans certains cas, la machine cliente peut simplement manquer de temps CPU. Pour être sur de
un test donné a vraiment mesuré les capacités du serveur et non celles du client, c'est un bon
idée de faire varier le nombre de machines participant à un test. Si la performance observée
reste le même car le nombre de machines clientes varie, les résultats des tests sont probables
pour être valable.

Utilisez httperf en ligne en utilisant les services onworks.net