Préparation au test des pages dynamiques
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 de 200 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)Il convient en particulier de 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.