Apache Bench - Guide rapide
Les tests de performance se sont révélés cruciaux pour le succès d'une entreprise. Non seulement un site peu performant subit des pertes financières, mais cela peut aussi parfois entraîner des répercussions juridiques.
Personne ne veut supporter un site lent et peu fiable dans des interactions en ligne importantes telles que les achats, les tests en ligne, le paiement de factures, etc. Avec Internet étant si largement disponible, la gamme d'alternatives est immense. Il est plus facile de perdre de la clientèle que d'en gagner et la performance change la donne.
Besoin d'un outil de test de charge
Si nous pouvons comprendre quel est le besoin d'un outil de test de charge, cela nous donnera la raison et la motivation de l'utiliser. Certains sites commerciaux célèbres ont subi de graves temps d'arrêt lorsqu'ils reçoivent un grand nombre de visiteurs. Les sites Web de commerce électronique investissent massivement dans les campagnes publicitaires, mais pas dans les tests de charge. Par conséquent, ils ne parviennent pas à garantir des performances système optimales, lorsque ce marketing génère du trafic.
Un autre exemple familier d'ignorance des tests de charge est celui de «l'erreur d'établissement de la connexion» dans les sites Web WordPress. Par conséquent, il est judicieux de tester en charge un site Web ou une application avant son déploiement en production. Il est agréable d'établir rapidement un scénario optimiste pour un projet avant d'exécuter des tests plus détaillés ultérieurement.
Qu'est-ce qu'Apache Bench?
Apache Bench (ab) est un outil de l'organisation Apache pour l'analyse comparative d'un serveur Web HTTP (Hypertext Transfer Protocol). Bien qu'il soit conçu pour mesurer les performances du serveur Web Apache, il peut également être utilisé pour tester tout autre serveur Web tout aussi bon. Avec cet outil, vous pouvez rapidement connaître le nombre de requêtes par seconde que votre serveur Web est capable de traiter.
Caractéristiques d'Apache Bench
Voyons les principales fonctionnalités et limitations d'Apache Bench. Les fonctionnalités et limitations sont répertoriées ci-dessous -
Étant un logiciel open source, il est disponible gratuitement.
Il s'agit d'un simple programme informatique en ligne de commande.
C'est un outil indépendant de la plate-forme. Cela signifie qu'il peut être appelé aussi bien sur Linux / Unix que sur un serveur Windows.
Il peut effectuer des tests de charge et de performances uniquement pour le serveur Web - HTTP ou HTTPS.
Ce n'est pas extensible.
Apache Bench utilise un seul thread du système d'exploitation quel que soit le niveau de concurrence (spécifié par l'indicateur -c). Par conséquent, lors de l'analyse comparative des serveurs haute capacité, une seule instance d'Apache Bench peut elle-même constituer un goulot d'étranglement. Pour saturer complètement l'URL cible, il est préférable d'utiliser des instances supplémentaires d'Apache Bench en parallèle, si votre serveur dispose de plusieurs cœurs de processeur.
Précaution
Vous devez être conscient qu'il n'y a pas de directive dans Apache Bench pour augmenter la concurrence à des intervalles particuliers lors de l'exécution des tests. Par conséquent, exécuter des tests de charge à l'aide de ab équivaut à une attaque par déni de service (DOS). Il est recommandé d'informer et d'obtenir l'autorisation préalable de votre fournisseur de services VPS si vous prévoyez d'effectuer des tests de charge lourde pendant une longue période. Ils vous attribueront un intervalle de temps approprié ou décaleront votre nœud pour la tâche de test de charge.
Deuxièmement, si vous testez le site Web d'un tiers en continu et pendant une longue période juste pour apprendre Apache Bench à partir de votre VPS (qui devient le nœud de test), il existe une possibilité distante que votre IP publique VPS puisse être bloquée par le site Web du tiers. en permanence. Dans ce cas, vous ne pourrez pas vous connecter à ce site Web avec la même adresse IP. Mais si vous souhaitez vraiment vous connecter au site Web à l'avenir, la seule solution sera de parler à l'administrateur système du site Web cible, ou de créer une nouvelle instance du serveur avec une adresse IP différente avec l'aide de votre fournisseur de services VPS.
Après vous avoir prévenu, permettez-moi de vous assurer que tous les tests de ce didacticiel sont suffisamment sûrs et sortent de ce que les administrateurs système appellent généralement les pratiques «d'abus du système».
Dans ce chapitre, nous vous expliquerons comment configurer votre environnement pour Apache Bench sur votre VPS.
Exigence du système
Memory - 128 Mo
Disk Space - Aucune exigence minimale
Operating System - Aucune exigence minimale
Installation d'Apache Bench
Apache Bench est une application autonome et n'a aucune dépendance sur l'installation du serveur Web Apache. Voici un processus en deux étapes pour installer Apache Bench.
Step 1 - Mettre à jour la base de données des packages.
# apt-get updateVeuillez noter que le symbole # avant une commande de terminal signifie que l'utilisateur root émet cette commande.
Step 2 - Installez le package apache2 utils pour accéder à Apache Bench.
# apt-get install apache2-utilsApache Bench est maintenant installé. Si vous souhaitez tester une application Web hébergée sur le même VPS, il suffit d'installer uniquement le serveur Web Apache -
# apt-get install apache2En tant qu'utilitaire Apache, Apache Bench est automatiquement installé lors de l'installation du serveur Web Apache.
Vérification de l'installation d'Apache Bench
Voyons maintenant comment vérifier l'installation d'Apache Bench. Le code suivant aidera à vérifier l'installation -
# ab -VOutput
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/Lorsque vous voyez la sortie du terminal ci-dessus, cela signifie que vous avez correctement installé Apache Bench.
Création d'un utilisateur Sudo privilégié
Du point de vue de la sécurité, il est considéré comme une bonne pratique pour l'administrateur système de créer un utilisateur sudo au lieu de travailler en tant que root. Nous allons créer un utilisateur de test, nommé test, dans le but -
# useradd -m -d /home/test -g sudo testDéfinissons le mot de passe du nouvel utilisateur -
# passwd testLe système demandera un nouveau mot de passe pour le test utilisateur. Vous pouvez entrer un mot de passe simple car nous ne faisons que tester et non déployer sur le serveur de production. Habituellement, la commande sudo vous invite à fournir le mot de passe de l'utilisateur sudo; il est recommandé de ne pas utiliser de mot de passe compliqué car le processus devient fastidieux.
Output
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfullyTest du site Web Apache.org
Dans cette section, nous testerons le site Web Apache.org. Passons d'abord au test utilisateur sudo -
# su testPour commencer, nous allons tester le site Web de l'organisation Apache, https://www.apache.org/. Nous allons d'abord exécuter la commande, puis comprendre la sortie -
$ ab -n 100 -c 10 https://www.apache.org/Ici -nest le nombre de requêtes à effectuer pour la session de benchmarking. Par défaut, il suffit d'exécuter une seule demande, ce qui conduit généralement à des résultats d'analyse comparative non représentatifs.
Et -cest la concurrence et indique le nombre de demandes multiples à effectuer à la fois. La valeur par défaut est une demande à la fois.
Ainsi, dans ce test, Apache Bench effectuera 100 requêtes avec concurrence de 10 au serveur d'organisation Apache.
Output
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.apache.org (be patient).....done
Server Software: Apache/2.4.7
Server Hostname: www.apache.org
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256
Document Path: /
Document Length: 58769 bytes
Concurrency Level: 10
Time taken for tests: 1.004 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 5911100 bytes
HTML transferred: 5876900 bytes
Requests per second: 99.56 [#/sec] (mean)
Time per request: 100.444 [ms] (mean)
Time per request: 10.044 [ms] (mean, across all concurrent requests)
Transfer rate: 5747.06 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 39 46 30.9 41 263
Processing: 37 40 21.7 38 255
Waiting: 12 15 21.7 13 230
Total: 77 86 37.5 79 301
Percentage of the requests served within a certain time (ms)
50% 79
66% 79
75% 80
80% 80
90% 82
95% 84
98% 296
99% 301
100% 301 (longest request)Après avoir exécuté notre premier test, il sera facile de reconnaître le modèle d'utilisation de cette commande qui est la suivante -
# ab [options .....] URLoù,
ab - Commande Apache Bench
options - drapeaux pour une tâche particulière que nous voulons effectuer
URL - URL du chemin que nous voulons tester
Comprendre les valeurs de sortie
Nous devons comprendre les différentes métriques pour comprendre les différentes valeurs de sortie renvoyées par ab. Voici la liste -
Server Software - C'est le nom du serveur Web renvoyé dans l'en-tête HTTP du premier retour réussi.
Server Hostname - C'est le DNS ou l'adresse IP donnée sur la ligne de commande.
Server Port- C'est le port auquel ab se connecte. Si aucun port n'est indiqué sur la ligne de commande, ce sera par défaut 80 pour http et 443 pour https.
SSL/TLS Protocol- C'est le paramètre de protocole négocié entre le client et le serveur. Cela ne sera imprimé que si SSL est utilisé.
Document Path - Il s'agit de l'URI de la demande analysée à partir de la chaîne de ligne de commande.
Document Length- Il s'agit de la taille en octets du premier document renvoyé avec succès. Si la longueur du document change pendant le test, la réponse est considérée comme une erreur.
Concurrency Level - Il s'agit du nombre de clients simultanés (équivalent aux navigateurs Web) utilisés pendant le test.
Time Taken for Tests - Il s'agit du temps écoulé entre le moment où la première connexion socket est créée et le moment où la dernière réponse est reçue.
Complete Requests - Le nombre de réponses réussies reçues.
Failed Requests- Le nombre de demandes considérées comme un échec. Si le nombre est supérieur à zéro, une autre ligne sera imprimée indiquant le nombre de demandes qui ont échoué en raison de la connexion, de la lecture, d'une longueur de contenu incorrecte ou d'exceptions.
Total Transferred- Le nombre total d'octets reçus du serveur. Ce nombre est essentiellement le nombre d'octets envoyés sur le câble.
HTML Transferred- Le nombre total d'octets de document reçus du serveur. Ce nombre exclut les octets reçus dans les en-têtes HTTP
Requests per second- C'est le nombre de requêtes par seconde. Cette valeur est le résultat de la division du nombre de demandes par le temps total nécessaire.
Time per request- Le temps moyen passé par demande. La première valeur est calculée avec la formule simultanéité * timeaken * 1000 / done tandis que la seconde valeur est calculée avec la formule timeaken * 1000 / done
Transfer rate - Le taux de transfert tel que calculé par la formule totalread / 1024 / timeaken.
Analyse rapide de la sortie du test de charge
Après avoir appris les en-têtes des valeurs de sortie de la commande ab, essayons d'analyser et de comprendre les valeurs de sortie pour notre test initial -
L'organisation Apache utilise son propre logiciel de serveur Web - Apache (version 2.4.7)
Le serveur écoute sur le port 443 à cause de https. Si cela avait été http, cela aurait été 80 (par défaut).
Le total des données transférées est de 58769 octets pour 100 requêtes.
Test terminé en 1,004 secondes. Aucune demande n'a échoué.
Requêtes par seconde - 99,56. Ceci est considéré comme un assez bon nombre.
Temps par requête - 100,444 ms (pour 10 requêtes simultanées). Donc, pour toutes les demandes, il est de 100,444 ms / 10 = 10,044 ms.
Taux de transfert - 1338,39 [Ko / s] reçus.
Dans les statistiques de temps de connexion, vous pouvez observer que de nombreuses requêtes ont dû attendre quelques secondes. Cela peut être dû au fait que le serveur Web Apache met les demandes en file d'attente.
Dans notre premier test, nous avions testé une application (ie, www.apache.org) hébergée sur un serveur différent. Dans la dernière partie du didacticiel, nous testerons nos exemples d'applications Web hébergées sur le même serveur à partir duquel nous exécuterons les tests ab. C'est pour faciliter l'apprentissage et la démonstration. Idéalement, le nœud hôte et le nœud de test doivent être différents pour une mesure précise.
Pour mieux apprendre ab, vous devez comparer et observer comment les valeurs de sortie varient pour différents cas au fur et à mesure que nous avançons dans ce didacticiel.
Tracer la sortie d'Apache Bench
Ici, nous allons tracer le résultat pertinent pour voir combien de temps le serveur prend à mesure que le nombre de demandes augmente. Pour cela, nous ajouterons le-g option dans la commande précédente suivie du nom du fichier (ici out.data) dans lequel les données de sortie ab seront sauvegardées -
$ ab -n 100 -c 10 -g out.data https://www.apache.org/Voyons maintenant le out.data avant de créer une intrigue -
$ less out.dataOutput
starttime seconds ctime dtime ttime wait
Tue May 30 12:11:37 2017 1496160697 40 38 77 13
Tue May 30 12:11:37 2017 1496160697 42 38 79 13
Tue May 30 12:11:37 2017 1496160697 41 38 80 13
...Voyons maintenant les en-têtes de colonne dans le out.data fichier -
starttime - Il s'agit de la date et de l'heure auxquelles l'appel a commencé.
seconds - Identique à l'heure de début mais au format d'horodatage Unix (date -d @ 1496160697 renvoie la sortie de l'heure de début).
ctime - C'est l'heure de connexion.
dtime - C'est le temps de traitement.
ttime - C'est le temps total (c'est la somme de ctime et dtime, mathématiquement ttime = ctime + dtime).
wait - C'est le temps d'attente.
Pour une visualisation illustrée de la manière dont ces éléments multiples sont liés les uns aux autres, jetez un œil à l'image suivante -
Si nous travaillons sur un terminal ou lorsque les graphiques ne sont pas disponibles, gnuplotest une excellente option. Nous le comprendrons rapidement en passant par les étapes suivantes.
Laissez-nous installer et lancer gnuplot -
$ sudo apt-get install gnuplot
$ gnuplotOutput
G N U P L O T
Version 4.6 patchlevel 6 last modified September 2014
Build System: Linux x86_64
Copyright (C) 1986-1993, 1998, 2004, 2007-2014
Thomas Williams, Colin Kelley and many others
gnuplot home: http://www.gnuplot.info
faq, bugs, etc: type "help FAQ"
immediate help: type "help" (plot window: hit 'h')
Terminal type set to 'qt'
gnuplot>Comme nous travaillons sur le terminal et supposons que les graphiques ne sont pas disponibles, nous pouvons choisir le terminal stupide qui donnera une sortie en ASCII sur le terminal lui-même. Cela nous aide à avoir une idée de ce à quoi ressemble notre intrigue avec cet outil rapide. Préparons maintenant le terminal pour le tracé ASCII.
gnuplot> set terminal dumbOutput
Terminal type set to 'dumb'
Options are 'feed size 79, 24'Comme notre terminal gnuplot est maintenant prêt pour le tracé ASCII, traçons les données du out.data fichier -
gnuplot> plot "out.data" using 9 w lOutput
1400 ++-----+------+-----+------+------+------+------+-----+------+-----++
+ + + + + + +"out.data" using 9 ****** +
| |
1200 ++ ********************************************
| ******************* |
1000 ++ * ++
| * |
| * |
800 ++ * ++
| * |
| * |
600 ++ * ++
| * |
| * |
400 ++ * ++
| * |
200 ++ * ++
| * |
+**** + + + + + + + + + +
0 ++-----+------+-----+------+------+------+------+-----+------+-----++
0 10 20 30 40 50 60 70 80 90 100Nous avons tracé le ttime, temps total (en ms) de la colonne 9, par rapport au nombre de requêtes. On peut remarquer que pour les dix requêtes initiales, le temps total était de près de 100 ms, pour les 30 requêtes suivantes (de la 10 ème à la 40 ème ), il est passé à 1100 ms, et ainsi de suite. Votre intrigue doit être différente en fonction de votreout.data.
Dans le chapitre précédent, nous avons compris l'utilisation de base d'Apache Bench pour tester un site Web tiers. Dans cette section, nous utiliserons cet outil pour tester une application Web sur notre propre serveur. Pour garder le tutoriel autonome dans la mesure du possible, nous avons choisi d'installer une application python à des fins de démonstration; vous pouvez choisir n'importe quel autre langage comme PHP ou Ruby en fonction de votre niveau d'expertise.
Installer Python
Généralement, Python est installé par défaut sur les serveurs Linux.
Installation de Bottle Framework et création d'une application simple
Bottle est un micro-framework écrit en python pour créer des applications Web, et pip est un gestionnaire de packages python. Tapez la commande suivante dans le terminal pour installer Bottle -
$ sudo apt-get install python-pip
$ sudo pip install bottleCréons maintenant une petite application Bottle. Pour cela, créez un répertoire et déplacez-vous dedans -
$ mkdir webapp
$ cd webappNous allons créer un nouveau script python, app.py, dans le répertoire webapp -
$ vim app.pyMaintenant, écrivez le code suivant dans le fichier app.py -
from bottle import Bottle, run
app = Bottle()
@app.route('/')
@app.route('/hello')
def hello():
return "Hello World!"
run(app, host = 'localhost', port = 8080)Lorsque vous avez ajouté les lignes ci-dessus, enregistrez et fermez le fichier. Après avoir enregistré le fichier, nous pouvons exécuter le script python pour lancer l'application -
$ python app.pyOutput
Bottle v0.12.7 server starting up (using WSGIRefServer())...
Listening on http://localhost:8080/
Hit Ctrl-C to quit.Cette sortie montre que notre application s'exécute sur la machine locale de l'hôte http://localhost et écoute sur le port 8080.
Vérifions si notre application répond correctement aux requêtes HTTP. Comme ce terminal ne peut accepter aucune entrée sans quitter l'application Bottle, nous devons nous connecter à notre VPS avec un autre terminal. Après vous être connecté au VPS avec un autre terminal, vous pouvez accéder à votre application en tapant le code suivant dans le nouveau terminal.
$ lynx http://localhost:8080/Lynx est un navigateur en ligne de commande et est généralement installé par défaut dans diverses distributions Linux telles que Debian et Ubuntu. Si vous voyez la sortie suivante, cela signifie que votre application fonctionne correctement.
Output
Si vous voyez la sortie ci-dessus, cela signifie que notre application est en ligne et prête à être testée.
Test de l'application avec le serveur Web de développement
Veuillez noter qu'il y a un bogue dans ab, et qu'il ne peut pas tester l'application sur l'hôte local. Nous allons donc changer l'hôte de localhost en 127.0.0.1 dans le fichier app.py. Ainsi, le fichier changera comme suit -
from bottle import Bottle, run
app = Bottle()
@app.route('/')
@app.route('/hello')
def hello():
return "Hello World!"
run(app, host = '127.0.0.1', port = 8080)Testons maintenant notre application en tapant la commande suivante sur le même terminal sur lequel a exécuté la commande lynx -
$ ab -n 100 -c 10 http://127.0.0.1:8080/helloOutput
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: WSGIServer/0.1
Server Hostname: 127.0.0.1
Server Port: 8080
Document Path: /hello
Document Length: 12 bytes
Concurrency Level: 10
Time taken for tests: 0.203 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 16500 bytes
HTML transferred: 1200 bytes
Requests per second: 493.78 [#/sec] (mean)
Time per request: 20.252 [ms] (mean)
Time per request: 2.025 [ms] (mean, across all concurrent requests)
Transfer rate: 79.56 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 0
Processing: 1 6 28.2 2 202
Waiting: 1 6 28.2 2 202
Total: 1 6 28.2 2 202
Percentage of the requests served within a certain time (ms)
50% 2
66% 2
75% 2
80% 2
90% 2
95% 2
98% 202
99% 202
100% 202 (longest request)Alors que la sortie sur la première borne sera (100 fois) comme suit -
...
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
...Vous pouvez observer comment les différentes valeurs du résultat ab ont changé par rapport au test initial.
Test de l'application avec un serveur Web multithread
Dans les tests précédents de ab, nous avons utilisé le serveur Web par défaut fourni dans le framework Bottle.
Nous allons maintenant changer le serveur Web par défaut à un seul thread par un serveur à plusieurs threads. Par conséquent, installons une bibliothèque de serveur Web multi-thread commecherrypy ou gunicornet dites à Bottle de l'utiliser. Nous avons choisi gunicorn à des fins de démonstration ici (vous pouvez également en choisir un autre) -
$ sudo apt-get install gunicornEt modifiez le fichier, c'est-à-dire le changement du serveur Web par défaut en gunicorn -
...
run(server = 'gunicorn'...)
...Testons l'application dans le deuxième terminal.
$ ab -n 100 -c 10 http://127.0.0.1:8080/helloOutput
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: gunicorn/19.0.0
Server Hostname: 127.0.0.1
Server Port: 8080
Document Path: /hello
Document Length: 12 bytes
Concurrency Level: 10
Time taken for tests: 0.031 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 17200 bytes
HTML transferred: 1200 bytes
Requests per second: 3252.77 [#/sec] (mean)
Time per request: 3.074 [ms] (mean)
Time per request: 0.307 [ms] (mean, across all concurrent requests)
Transfer rate: 546.36 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.9 0 4
Processing: 1 2 0.7 3 4
Waiting: 0 2 0.8 2 3
Total: 2 3 0.6 3 5
WARNING: The median and mean for the initial connection time are not within a normal
deviation These results are probably not that reliable.
WARNING: The median and mean for the processing time are not within a normal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 3
80% 3
90% 4
95% 5
98% 5
99% 5
100% 5 (longest request)Observez comment les requêtes par seconde sont passées de 493 à 3252. Cela signifie que gunicorn convient comme serveur de production pour les applications python.
Dans ce chapitre, nous allons apprendre à tester plusieurs URL simultanément. Pour cela, nous devrons éditer notre fichier d'application, app.py pour inclure deux URL -
from bottle import Bottle, run
app = Bottle()
@app.route('/')
@app.route('/hello1')
def hello():
return "Hello World! It is first URL."
@app.route('/hello2')
def hello():
return "Hello World! It is second URL."
run(app,server = 'gunicorn',host = '127.0.0.1', port = 8080)Création d'un script Shell simple
Vous pouvez le faire en créant un script shell, avec plusieurs appels ab. Créez un fichier test.sh et ajoutez-y les lignes suivantes -
ab -n 100 -c 10 http://127.0.0.1:8080/hello1
ab -n 100 -c 10 http://127.0.0.1:8080/hello2Lorsque vous avez ajouté les lignes ci-dessus, enregistrez et fermez le fichier. Rendre le fichier exécutable -
chmod u+x test.shLançons maintenant le script -
./test.shPour éviter les répétitions et à des fins de clarté, nous montrerons uniquement le contenu pertinent de la sortie ab, en indiquant par des points quelle partie a été omise, comme dans ce qui suit.
Production
.
.
.
Document Path: /hello1
Document Length: 732 bytes
Concurrency Level: 10
Time taken for tests: 0.040 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Total transferred: 90000 bytes
HTML transferred: 73200 bytes
Requests per second: 2496.13 [#/sec] (mean)
Time per request: 4.006 [ms] (mean)
Time per request: 0.401 [ms] (mean, across all concurrent requests)
Transfer rate: 2193.87 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.8 0 3
Processing: 1 3 1.0 4 5
Waiting: 0 3 1.2 4 4
Total: 1 4 0.6 4 5
WARNING: The median and mean for the processing time are not within a normal deviation
These results are probably not that reliable.
.
.
.Script Shell pour enregistrer la sortie du banc Apache dans un fichier
Vous pouvez enregistrer la sortie Apache Bench dans un fichier en créant un script shell, avec plusieurs appels ab. À la fin de chaque ligne, placez un&;cela fait que la commande s'exécute en arrière-plan et laisse la commande suivante commencer son exécution. Vous voudrez également rediriger la sortie vers un fichier pour chaque URL en utilisant <filename>. Par exemple, notre fichier test.sh ressemblera à ce qui suit après modification -
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello1 > test1.txt &
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello2 > test2.txt &Ici, test1.txt et test2.txt sont les fichiers pour enregistrer les données de sortie.
Vous pouvez vérifier que le script ci-dessus a créé deux fichiers, test1.txt et test2.txt qui contiennent la sortie ab pour les URL respectives -
$ ls -lProduction
...
-rw-r--r-- 1 root root 5225 May 30 12:11 out.data
-rwxr--r-- 1 root root 118 Jun 10 12:24 test.sh
-rw-r--r-- 1 root root 1291 Jun 10 12:31 test1.txt
-rwxr--r-- 1 root root 91 Jun 10 13:22 test2.sh
-rw-r--r-- 1 root root 1291 Jun 10 12:31 test2.txt
...Situation de vigilance
Lorsque vous utilisez ab, vous devez être attentif à l'échec du test sans avertissement. Par exemple, si vous vérifiez une mauvaise URL, vous pouvez obtenir quelque chose de similaire à ce qui suit (nous avons délibérément changé le port ici).
$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:805/Production
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software:
Server Hostname: 127.0.0.1
Server Port: 805
Document Path: /
Document Length: Variable
Concurrency Level: 10
Time taken for tests: 0.002 seconds
Complete requests: 100
Failed requests: 150
(Connect: 0, Receive: 100, Length: 0, Exceptions: 50)
Keep-Alive requests: 0
Total transferred: 0 bytes
HTML transferred: 0 bytes
Requests per second: 44984.26 [#/sec] (mean)
Time per request: 0.222 [ms] (mean)
Time per request: 0.022 [ms] (mean, across all concurrent requests)
Transfer rate: 0.00 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 0 0 0.2 0 0
Waiting: 0 0 0.0 0 0
Total: 0 0 0.2 0 0
Percentage of the requests served within a certain time (ms)
50% 0
66% 0
75% 0
80% 0
90% 0
95% 0
98% 0
99% 0
100% 0 (longest request)Dans ce chapitre, nous comprendrons la préparation nécessaire pour tester les pages dynamiques. Une page Web dynamique côté serveur est une page Web dont la construction est contrôlée par un serveur d'applications traitant des scripts côté serveur. Le banc Apache peut uniquement tester la charge de la page Web dynamique côté serveur.
Niveau de concurrence et nombre total de demandes
Le niveau de concurrence doit être inférieur au nombre total de demandes.
$ ab -l -r -n 30 -c 80 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/Output
ab: Cannot use concurrency level greater than total number of requests
Usage: ab [options] [http[s]://]hostname[:port]/pathUtilisation de drapeaux
Dans cette section, nous décrirons l'utilisation de quelques indicateurs importants avec la commande ab. Nous utiliserons les termes, options et indicateurs de manière interchangeable.
Verbeux -v
L'option détaillée peut être utilisée pour analyser et déboguer s'il existe plusieurs nombres de demandes ayant échoué. Une indication courante d'échec du test de charge est que le test se termine très rapidement et qu'il donne un bon nombre de requêtes par seconde. Mais ce sera une mauvaise référence. Pour identifier le succès ou l'échec, vous pouvez utiliser le-v 2option qui videra le corps et l'en-tête de chaque réponse sur la sortie du terminal. La commande suivante décrit un cas d'utilisation -
$ ab -n 1 -v 2 http://www.generic-example-URL.com/Output
LOG: header received:
HTTP/1.0 200 OK
…
Content-Length: 2548687Bien sûr, si vous testez des réponses variables ou renvoyez des codes HTTP autres que 200 en cas d'erreur, vous devez simplement ignorer la vérification de la longueur avec le -loption. Nous verrons bientôt du HTTP non-200 lorsque nous lancerons une application web2py dans les chapitres suivants.
Keep-alive -k
Lorsque le client envoie une requête HTTP, la connexion est établie avec le serveur, le serveur envoie la réponse et la connexion est fermée après avoir envoyé la requête. Ce cycle se poursuit à chaque demande. Cependant, avec le paramètre keep-alive (également connu sous le nom de connexions persistantes), le client maintient une connexion TCP sous-jacente ouverte pour faciliter plusieurs demandes et réponses; cela élimine le temps d'initialisation de connexion lent et coûteux qui serait autrement présent.
Longueur de document variable -l
Si la page Web est de longueur variable, vous devez utiliser l'option -l. Apache Bench ne signale pas les erreurs si la longueur des réponses n'est pas constante. Cela peut être utile pour les pages dynamiques.
Utilisation de l'option -r
Comment forcer ab à ne pas quitter lors de la réception d'erreurs? Vous devez utiliser l'option-r. Sans cette option, votre test peut être interrompu dès qu'une requête rencontre l'erreur de socket. Cependant, avec cette option, les erreurs seront signalées dans l'en-tête des erreurs ayant échoué, mais le test se poursuivra jusqu'à la fin.
Utilisation de l'option -H
Cette option est utilisée pour ajouter une ligne d'en-tête arbitraire. L'argument se présente généralement sous la forme d'une ligne d'en-tête valide, contenant une paire champ-valeur séparée par deux-points (c'est-à-dire «Accept-Encoding: zip / zop; 8 bits»).
Utilisation de l'option -C
Dans la section suivante, nous apprendrons en détail comment utiliser les options ci-dessus en combinaison avec l'option d'utiliser la valeur du cookie, c'est-à-dire le -Coption. L'option -C se présente généralement sous la forme d'unname = valuepaire. Ce champ peut être répété.
Utilisation du cookie de session avec Apache Bench
Pour comprendre comment utiliser le cookie avec Apache Bench, nous avons besoin d'une page Web qui tente de définir un cookie. Un très bon exemple est l'application web2py qui est un framework web python.
Installation de web2py
Nous allons installer rapidement une autre application python web2py. Vous pouvez en savoir plus sur son utilisation sur la présentation de Web2py Framework .
Python est généralement installé par défaut sur les serveurs Ubuntu et Debian. Par conséquent, une condition est déjà remplie pour exécuter web2py avec succès.
Cependant, nous devons installer le package unzip pour extraire les fichiers source de web2py du fichier zip que nous allons télécharger -
$ sudo apt-get update
$ sudo apt-get install unzipRécupérons le framework web2py sur le site Web du projet. Nous allons télécharger ceci dans notre dossier personnel -
$cd ~
$ wget http://www.web2py.com/examples/static/web2py_src.zipMaintenant, nous pouvons décompresser le fichier que nous venons de télécharger et déplacer à l'intérieur -
$ unzip web2py_src.zip
$ cd web2pyPour exécuter le web2py, vous n'avez pas besoin de l'installer. Une fois que vous êtes dans le répertoire web2py, vous pouvez l'exécuter en tapant la commande suivante -
$python web2py.pySi tout réussit, vous verrez la sortie suivante où il vous sera demandé de choisir un mot de passe pour l'interface utilisateur administrative -
web2py Web Framework
Created by Massimo Di Pierro, Copyright 2007-2017
Version 2.14.6-stable+timestamp.2016.05.10.00.21.47
Database drivers available: sqlite3, imaplib, pymysql, pg8000
WARNING:web2py:GUI not available because Tk library is not installed
choose a password:
please visit:
http://127.0.0.1:8000/
use "kill -SIGTERM 23904" to shutdown the web2py serverCependant, vous devez être conscient du fait que l'interface Web lancée est accessible uniquement sur la machine locale.
À partir de la sortie, vous pouvez comprendre que pour arrêter le serveur Web, vous devrez taper «CTRL-C» dans le terminal instantané. D'autre part, pour arrêter le serveur web2py sur l'autre terminal lié au même VPS, vous pouvez insérer la commande kill -SIGTERM <PID>, où <PID> est l'ID de processus du serveur web2py, qui dans ce cas est 23904.
Cookie de session de web2py
Si une page n'est accessible que par un utilisateur connecté, pas directement accessible depuis la page de connexion, dans ce cas, vous pouvez utiliser le -Cdrapeau. Cet indicateur définit un cookie pour la commande ab. Mais vous devez obtenir la valeur du cookie d'identifiant de session à partir d'une session valide. Comment l'obtenir? Divers tutoriels en ligne vous guideront vers les outils de développement de navigateur Chrome (ou Mozilla). Mais dans notre cas de test, comme l'application n'est disponible que sur la ligne de commande, nous utiliserons le navigateur lynx pour obtenir la valeur.
Obtenons d'abord la valeur du cookie d'une session. Ouvrez un autre terminal et tapez la commande suivante -
$ lynx http://127.0.0.1:8000/En réponse à la commande ci-dessus, lynx vous demandera la permission d'accepter le cookie du serveur web2py comme indiqué dans l'image ci-dessous.
Notez la valeur du cookie avant de taper ypour accepter le cookie. Maintenant, le terminal ressemblera à l'image suivante - site Web sur le terminal!
Après avoir obtenu la valeur du cookie, nous allons maintenant exécuter le test ab. Pour cela, nous devrons ouvrir le troisième terminal (voir l'image ci-dessous) -
Maintenant, utilisons le drapeau -C dans le troisième terminal -
$ ab -n 100 -c 10 -C session_name = 127.0.0.1-643dad04-3c34 http://127.0.0.1:8000/Production
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: 66 bytes
Concurrency Level: 10
Time taken for tests: 0.051 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Total transferred: 27700 bytes
HTML transferred: 6600 bytes
Requests per second: 1968.12 [#/sec] (mean)
Time per request: 5.081 [ms] (mean)
Time per request: 0.508 [ms] (mean, across all concurrent requests)
Transfer rate: 532.39 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.9 2 4
Processing: 0 3 0.9 3 5
Waiting: 0 2 1.1 2 4
Total: 4 5 0.7 5 7
Percentage of the requests served within a certain time (ms)
50% 5
66% 5
75% 5
80% 6
90% 6
95% 6
98% 7
99% 7
100% 7 (longest request)De la sortie ci-dessus, nous notons plusieurs points. Tout d'abord, web2py utilise le serveur Web Rocket . Nous notons également que nous obtenons des «réponses non-2xx» en plus des en-têtes discutés précédemment dans la sortie. En général, le protocole Http répond à une demande en utilisant un code de réponse, et tout ce qui se trouve dans la plage des 200s signifie «ok», et le reste correspond à un problème. Par exemple, les 400 sont des erreurs liées aux ressources telles que 404 Fichier introuvable. Les 500 correspondent à des erreurs de serveur. Dans notre cas présent, il n'y a aucune erreur nulle part sauf lorsque nous utilisons l'option -C. Il peut être supprimé en utilisant l'option -l comme déjà décrit.
Vérification de la page d'administration
Dans cette section, nous allons comprendre comment vérifier la page d'administration. A titre de comparaison, testons une autre URL de l'application web2py -
$ ab -n 100 -c 10 session_name = 127.0.0.1-643dad04-3c34 http://127.0.0.1:8000/adminProduction
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /admin
Document Length: 8840 bytes
Concurrency Level: 10
Time taken for tests: 2.077 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 926700 bytes
HTML transferred: 884000 bytes
Requests per second: 48.14 [#/sec] (mean)
Time per request: 207.749 [ms] (mean)
Time per request: 20.775 [ms] (mean, across all concurrent requests)
Transfer rate: 435.61 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.2 0 12
Processing: 62 204 52.2 199 400
Waiting: 61 203 52.0 199 400
Total: 62 205 54.3 199 411
Percentage of the requests served within a certain time (ms)
50% 199
66% 211
75% 220
80% 226
90% 264
95% 349
98% 381
99% 411
100% 411 (longest request)Vous devez en particulier noter les statistiques respectives dans les sections «Temps de connexion» et «Pourcentage des demandes traitées…» de http://127.0.0.1:8000/ et http://127.0.0.1:8000/admin. Il ya une énorme différence.
Utilisation de l'option Timelimit
Généralement, l'option Timelimit est délicate. Comprenons cela à partir du manuel de ab , qui est assez explicatif -
-t timelimit
Maximum number of seconds to spend for benchmarking. This implies a -n 50000 internally.
Use this to benchmark the server within a fixed total amount of time.
Per default there is no timelimit.Faisons un test avec cette option. Nous noterons nos observations après le passage par la sortie -
$ ab -n 100 -c 10 -t 60 http://127.0.0.1:8000/Production
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: 66 bytes
Concurrency Level: 10
Time taken for tests: 22.547 seconds
Complete requests: 50000
Failed requests: 0
Non-2xx responses: 50000
Total transferred: 13850000 bytes
HTML transferred: 3300000 bytes
Requests per second: 2217.61 [#/sec] (mean)
Time per request: 4.509 [ms] (mean)
Time per request: 0.451 [ms] (mean, across all concurrent requests)
Transfer rate: 599.88 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 0.8 2 8
Processing: 0 2 3.2 2 218
Waiting: 0 2 3.2 2 218
Total: 2 4 3.1 4 220
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 5
90% 5
95% 5
98% 7
99% 8
100% 220 (longest request)Notez que la sortie montre que cette option remplace le nombre de requêtes spécifié par le -noption et continue jusqu'aux 50K demandes. Cependant, comme les demandes ont été traitées très rapidement, ab a pris fin dès que 50k mark a été atteint - dans les 22 secondes (voir la rubrique Durée des tests) dans le cas présent.
Vous pouvez tester la même commande en remplaçant http://127.0.0.1:8000/ avec http://127.0.0.1:8000/admin (en supposant que ce soit notre application web2py) ou un site Web tiers comme https://www.apache.org/, notez la différence dans les statistiques.
Liste de contrôle avant d'effectuer le test de charge
Il existe quelques vérifications qui vous aideront à exécuter le test avec succès et à mesurer les performances avec précision. Tenez compte des conditions suivantes avant d'effectuer le test de charge -
Assurez-vous qu'aucun module Python supplémentaire n'est chargé.
Pour éviter l'épuisement des ports TCP / IP, vous devez généralement attendre 2 à 3 minutes avant de passer à un autre test ab.
Assurez-vous que le nombre de connexions simultanées est inférieur à celui des threads de travail Apache.
Vous devez redémarrer le serveur avant d'effectuer un autre test, si Apache ou python plante.
Dans ce chapitre, nous décrirons les différentes combinaisons de -n et -c avec les indicateurs importants pour augmenter progressivement la charge sur votre serveur Web.
Vous devez principalement vous concentrer sur la façon dont les métriques suivantes changent lorsque vous augmentez la charge -
- Requêtes par seconde
- Temps de connexion (ms)
- Pourcentage des demandes traitées dans un certain temps (ms)
Vous devriez également remarquer la valeur de seuil lorsque le serveur commence à se bloquer et que vous commencez à recevoir des demandes ayant échoué.
1 utilisateur simultané effectuant 100 visites de pages
Faisons 100 chargements de pages séquentiels par un seul utilisateur -
$ ab -l -r -n 100 -c 1 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/Production
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: Variable
Concurrency Level: 1
Time taken for tests: 0.045 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Keep-Alive requests: 0
Total transferred: 27700 bytes
HTML transferred: 6600 bytes
Requests per second: 2206.24 [#/sec] (mean)
Time per request: 0.453 [ms] (mean)
Time per request: 0.453 [ms] (mean, across all concurrent requests)
Transfer rate: 596.80 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 0 0 0.0 0 0
Waiting: 0 0 0.0 0 0
Total: 0 0 0.0 0 1
Percentage of the requests served within a certain time (ms)
50% 0
66% 0
75% 0
80% 0
90% 1
95% 1
98% 1
99% 1
100% 1 (longest request)5 utilisateurs simultanés effectuant chacun 10 visites de page
Ce cas correspond à une charge de pointe sur un site Web qui reçoit environ 50000 visites par mois.
$ ab -l -r -n 10 -c 5 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/Dans les sorties suivantes, nous omettons l'en-tête commun à des fins de clarté.
Production
...
Requests per second: 2009.24 [#/sec] (mean)
Time per request: 2.488 [ms] (mean)
Time per request: 0.498 [ms] (mean, across all concurrent requests)
Transfer rate: 543.52 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.5 1 2
Processing: 0 1 0.5 1 2
Waiting: 0 1 0.5 1 1
Total: 2 2 0.4 3 3
ERROR: The median and mean for the total time are more than twice the standard
deviation apart. These results are NOT reliable.
Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 3
80% 3
90% 3
95% 3
98% 3
99% 3
100% 3 (longest request)10 utilisateurs simultanés effectuant chacun 10 visites de page
Ce test correspond à 100 chargements de pages par 10 utilisateurs simultanés différents, chaque utilisateur effectue 10 chargements de pages séquentiels.
$ ab -r -n 10 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/Production
...
Requests per second: 2225.68 [#/sec] (mean)
Time per request: 4.493 [ms] (mean)
Time per request: 0.449 [ms] (mean, across all concurrent requests)
Transfer rate: 602.07 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 3
Processing: 0 2 1.0 2 3
Waiting: 0 1 1.0 2 3
Total: 4 4 0.3 4 4
WARNING: The median and mean for the waiting time are not within a normal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 4
90% 4
95% 4
98% 4
99% 4
100% 4 (longest request)20 utilisateurs simultanés effectuant chacun 20 visites de page
Ce test correspond à 400 chargements de pages par 20 utilisateurs simultanés différents, chaque utilisateur effectue 20 chargements de pages séquentiels.
$ ab -r -n 20 -c 20 -k -H “Accept-Encoding: gzip, deflate” http://127.0.0.1:8000/Production
...
Requests per second: 1619.96 [#/sec] (mean)
Time per request: 12.346 [ms] (mean)
Time per request: 0.617 [ms] (mean, across all concurrent requests)
Transfer rate: 438.21 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 6 2.3 6 10
Processing: 1 5 2.9 5 10
Waiting: 0 5 2.9 5 9
Total: 10 11 0.6 11 12
Percentage of the requests served within a certain time (ms)
50% 11
66% 11
75% 12
80% 12
90% 12
95% 12
98% 12
99% 12
100% 12 (longest request)30 utilisateurs simultanés effectuant chacun 30 visites de page
Ce test correspond à 900 chargements de pages par 30 utilisateurs simultanés différents, chaque utilisateur effectue 30 chargements de pages séquentiels.
$ ab -r -n 30 -c 30 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/Production
...
Requests per second: 2283.45 [#/sec] (mean)
Time per request: 13.138 [ms] (mean)
Time per request: 0.438 [ms] (mean, across all concurrent requests)
Transfer rate: 617.69 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 6 2.7 6 11
Processing: 1 6 3.1 6 11
Waiting: 0 5 3.2 5 10
Total: 11 12 0.5 12 13
Percentage of the requests served within a certain time (ms)
50% 12
66% 12
75% 12
80% 12
90% 13
95% 13
98% 13
99% 13
100% 13 (longest request)Nous avons maintenant appris à augmenter progressivement la charge sur le site et à tester ses performances.
Dans ce chapitre, nous comparerons les sorties avec et sans indicateurs. Voyons comment l'utilisation d'indicateurs appropriés peut augmenter les performances de votre application Web. Avant cela, nous devons comprendre comment si votre application est simple, vous ne remarquerez peut-être pas la différence. Comme c'est le cas avec notre application simple, avec et sans drapeaux. Ensuite, nous effectuerons le même test avechttps://www.apache.org/ URL, et voyez la différence.
Tester notre application sans drapeaux
Dans cette section, nous allons comprendre comment tester notre application sans drapeaux.
$ ab -n 100 -c 10 http://127.0.0.1:8000/Production
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: Variable
Concurrency Level: 10
Time taken for tests: 0.244 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Keep-Alive requests: 0
Total transferred: 27700 bytes
HTML transferred: 6600 bytes
Requests per second: 2208.77 [#/sec] (mean)
Time per request: 4.527 [ms] (mean)
Time per request: 0.453 [ms] (mean, across all concurrent requests)
Transfer rate: 597.49 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 3
Processing: 0 2 0.7 2 4
Waiting: 0 2 1.0 2 3
Total: 4 4 0.3 4 5
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 5
80% 5
90% 5
95% 5
98% 5
99% 5
100% 5 (longest request)Tester notre application avec des drapeaux
Dans cette section, nous allons comprendre comment tester notre application avec des indicateurs.
$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/Production
...
Requests per second: 2277.07 [#/sec] (mean)
Time per request: 4.392 [ms] (mean)
Time per request: 0.439 [ms] (mean, across all concurrent requests)
Transfer rate: 615.97 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 3
Processing: 0 2 0.7 2 4
Waiting: 0 2 1.0 2 3
Total: 4 4 0.2 4 5
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 4
90% 5
95% 5
98% 5
99% 5
100% 5 (longest request)Nous pouvons simplement noter qu'il n'y a pas beaucoup de différence entre les statistiques de sortie.
Test du site Web de l'organisation Apache sans drapeaux
Voyons maintenant comment tester le site Web de l'organisation Apache sans indicateurs.
$ ab -n 100 -c 10 http://www.apache.org/Production
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.apache.org (be patient).....done
Server Software: Apache/2.4.7
Server Hostname: www.apache.org
Server Port: 80
Document Path: /
Document Length: 58433 bytes
Concurrency Level: 10
Time taken for tests: 1.498 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 5877500 bytes
HTML transferred: 5843300 bytes
Requests per second: 66.74 [#/sec] (mean)
Time per request: 149.840 [ms] (mean)
Time per request: 14.984 [ms] (mean, across all concurrent requests)
Transfer rate: 3830.58 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 12 110 295.2 12 1012
Processing: 37 38 0.5 38 39
Waiting: 12 13 0.3 13 15
Total: 49 147 295.4 50 1051
Percentage of the requests served within a certain time (ms)
50% 50
66% 50
75% 50
80% 50
90% 816
95% 1050
98% 1051
99% 1051
100% 1051 (longest request)Test du site Web de l'organisation Apache avec des indicateurs
Testons maintenant le site Web de l'organisation Apache avec des indicateurs.
$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://www.apache.org/Production
...
Document Length: Variable
Concurrency Level: 10
Time taken for tests: 0.357 seconds
Complete requests: 100
Failed requests: 0
Keep-Alive requests: 100
Total transferred: 1358510 bytes
HTML transferred: 1317700 bytes
Requests per second: 280.28 [#/sec] (mean)
Time per request: 35.678 [ms] (mean)
Time per request: 3.568 [ms] (mean, across all concurrent requests)
Transfer rate: 3718.41 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.7 0 12
Processing: 14 17 21.3 15 227
Waiting: 14 17 21.3 14 227
Total: 14 18 21.5 15 227
Percentage of the requests served within a certain time (ms)
50% 15
66% 15
75% 15
80% 15
90% 27
95% 28
98% 29
99% 227
100% 227 (longest request)Vous pouvez simplement noter comment la demande par seconde a augmenté avec l'utilisation des indicateurs. Dans le cas présent, il est notamment dû à l'utilisation de-H "Accept-Encoding: gzip, deflate car cet indicateur indique au serveur Apache de servir les requêtes dans gzipped format.
Prise en compte des résultats du banc Apache
Quelques points importants doivent être pris en compte en ce qui concerne les résultats d'Apache Bench. Cela nous aidera à concevoir notre stratégie globale pour supprimer les goulots d'étranglement dans notre application et améliorer ses performances.
Nous avons besoin de demandes par seconde. Cela nous donne une idée de la façon dont la configuration de notre serveur Web fonctionne; plus le nombre est élevé, meilleures sont les performances. Viennent ensuite les temps de connexion (ms) et le pourcentage des demandes servies. Vous devrez peut-être modifier les paramètres de votre serveur Web pour modifier ces mesures en fonction des performances souhaitées.
Vérifiez s'il y a des erreurs dans les journaux d'erreurs d'Apache ou du serveur Web utilisé ou dans les journaux (généraux). Au fur et à mesure que vous augmenterez votre charge, les choses commenceront à s'étouffer: des problèmes de mémoire commenceront à apparaître. De nombreux scripts python commenceront à planter s'ils ne sont pas écrits avec la simultanéité à l'esprit.
Vous avez besoin de savoir quelle est la valeur de concurrence critique au-dessus de laquelle votre serveur Web plante et / ou expire? Normalement, cela devrait se produire à un niveau de concurrence assez élevé. Si cette valeur est basse, quelque chose ne va pas et vous devez ajuster ces paramètres plus bas / plus haut.
Conclusion
Dans ce didacticiel, nous avons appris comment Apache Bench peut être utilisé pour tester le chargement de tout site Web ou application Web. Apache Bench peut être un outil très précieux pour déterminer comment la configuration de votre serveur d'applications Web doit être améliorée, pour réduire les goulots d'étranglement et augmenter les performances. Maintenant que vous êtes familiarisé avec l'utilisation de base d'Apache Bench, vous pouvez commencer par créer de nouveaux plans de test pour mesurer les performances de vos applications dans divers scénarios.