test de charge ab
Quelqu'un peut-il me guider, s'il vous plaît, dans le processus de chargement de mon site Web avec Apache bench tool (ab)?
Je veux savoir ce qui suit:
Combien de personnes par minute le site peut-il gérer?
Merci de me guider dans les commandes que je devrais exécuter pour comprendre cela.
J'ai essayé tous les tutoriels, et ils sont déroutants.
L'outil de référence Apache est très basique et, s'il vous donne une bonne idée de certaines performances, c'est une mauvaise idée de ne dépendre de cela que si vous envisagez de soumettre votre site à de graves contraintes de production.
Cela dit, voici les paramètres les plus courants et les plus simples:
-c: ("simultanéité"). Indique le nombre de clients (personnes/utilisateurs) qui viseront le site en même temps. Pendant l'exécution de ab, il y aura des clients -c sur le site. C’est ce qui détermine réellement le niveau de stress que votre site subira au cours du test.
-n: indique le nombre de demandes à effectuer. Cela ne fait que décider de la longueur du repère. Une valeur -n élevée avec une valeur -c que votre serveur peut prendre en charge est une bonne idée pour vous assurer que les choses ne se cassent pas sous un stress continu: ce n'est pas pareil de supporter un stress pendant 5 secondes que pendant 5 heures.
-k: Ceci fait la nature des navigateurs "KeepAlive" par nature. Vous n'avez pas besoin de passer une valeur pour -k car elle est "boolean" (ce qui signifie que vous souhaitez que votre test utilise l'en-tête Keep Alive de HTTP et maintienne la connexion). Étant donné que les navigateurs le font et qu'il est probable que vous voudrez simuler le stress et les flux de votre site, il est recommandé d'effectuer une analyse comparative avec ceci.
Le dernier argument est simplement l'hôte. Par défaut, il utilisera le protocole http: // si vous ne le spécifiez pas.
ab -k -c 350 -n 20000 example.com/
En exécutant la commande ci-dessus, vous utiliserez http://example.com/ avec 350 connexions simultanées jusqu'à ce que 20 000 demandes soient satisfaites. Cela sera fait en utilisant l'en-tête Keep Alive.
Une fois que le processus aura terminé les 20 000 demandes, vous recevrez des commentaires sur les statistiques. Cela vous indiquera la performance du site sous le stress que vous lui avez attribué lors de l'utilisation des paramètres ci-dessus.
Pour savoir combien de personnes le site peut gérer en même temps, il suffit de voir si les temps de réponse (moyennes, temps de réponse minimum et maximum, demandes ayant échoué, etc.) sont des nombres que votre site peut accepter (différents sites peuvent souhaiter des vitesses différentes). Vous pouvez exécuter l'outil avec différentes valeurs -c jusqu'à ce que vous atteigniez l'endroit où vous dites "Si je l'augmente, les demandes échouant commencent et les commandes sont cassées".
Selon votre site Web, vous vous attendez à un nombre moyen de demandes par minute. Cela varie tellement que vous ne pourrez pas simuler cela avec ab. Cependant, réfléchissez-y de la manière suivante: si votre utilisateur moyen frappe 5 demandes par minute et que le temps de réponse moyen que vous trouvez valide est de 2 secondes, cela signifie que 10 secondes sur une minute, 1 utilisateur sera sur les demandes, ce qui signifie uniquement 1/6 du temps, il frappera le site. Cela signifie également que si vous avez 6 utilisateurs accédant au site avec ab simultanément, vous aurez probablement 36 utilisateurs en simulation, même si votre niveau de simultanéité (-c) n'est que de 6.
Cela dépend du comportement que vous attendez de vos utilisateurs qui utilisent le site, mais vous pouvez l’obtenir de «Je m'attends à ce que mon utilisateur traite X demandes à la minute et j’estime qu’un temps de réponse moyen est valide s’il est de 2 secondes». Ensuite, modifiez simplement votre niveau -c jusqu'à ce que vous atteigniez 2 secondes de temps de réponse moyen (mais assurez-vous que le temps de réponse maximal et stddev sont toujours valables) et voyez à quel point vous pouvez obtenir -c.
J'espère que j'ai expliqué cela clairement :) Bonne chance
Merci de me guider dans les commandes que je devrais exécuter pour comprendre cela.
Le test le plus simple que vous pouvez faire consiste à effectuer 1 000 requêtes, 10 à la fois (ce qui simule environ 10 utilisateurs simultanés obtenant 100 pages chacun - sur la durée du test).
ab -n 1000 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://www.example.com/
-n 1000 est le nombre de demandes à effectuer.
-c 10 indique à AB de faire 10 demandes à la fois, au lieu de 1 demande à la fois, afin de mieux simuler les visiteurs simultanés (par opposition aux visiteurs séquentiels).
-k envoie l'en-tête KeepAlive, qui demande au serveur Web de ne pas fermer la connexion après chaque demande mais de continuer à la réutiliser.
J'envoie également l'en-tête supplémentaire Accept-Encoding: gzip, deflate car mod_deflate est presque toujours utilisé pour compresser la sortie text/html de 25% à 75% - les effets de ce dernier ne doivent pas être ignorés en raison de leur impact sur les performances globales du serveur Web (c'est-à-dire , peut transférer 2x les données dans le même laps de temps, etc.).
Résultats:
Benchmarking www.example.com (be patient)
Completed 100 requests
...
Finished 1000 requests
Server Software: Apache/2.4.10
Server Hostname: www.example.com
Server Port: 80
Document Path: /
Document Length: 428 bytes
Concurrency Level: 10
Time taken for tests: 1.420 seconds
Complete requests: 1000
Failed requests: 0
Keep-Alive requests: 995
Total transferred: 723778 bytes
HTML transferred: 428000 bytes
Requests per second: 704.23 [#/sec] (mean)
Time per request: 14.200 [ms] (mean)
Time per request: 1.420 [ms] (mean, across all concurrent requests)
Transfer rate: 497.76 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 5 14 7.5 12 77
Waiting: 5 14 7.5 12 77
Total: 5 14 7.5 12 77
Percentage of the requests served within a certain time (ms)
50% 12
66% 14
75% 15
80% 16
90% 24
95% 29
98% 36
99% 41
100% 77 (longest request)
Pour une interprétation plus simple, ignorez tout MAIS cette ligne:
Requests per second: 704.23 [#/sec] (mean)
Multipliez cela par 60 et vous avez vos demandes à la minute.
Pour obtenir des résultats concrets, testez Wordpress au lieu d'un fichier HTML statique ou d'un fichier index.php, car vous devez savoir comment tout fonctionne ensemble: y compris le code complexe PHP et plusieurs requêtes MySQL ...
Par exemple, voici les résultats du test d’une nouvelle installation de Wordpress sur le même système et le même environnement WAMP (j’utilise WampDeveloper, mais il existe aussi Xampp, WampServer et autres) ...
Requests per second: 18.68 [#/sec] (mean)
C'est 37 fois plus lent maintenant!
Après le test de charge, vous pouvez améliorer le rendement global (requêtes à la seconde) de différentes manières et rendre le serveur Web plus stable sous une charge plus importante (par exemple, augmenter le -n et le -c tend à planter Apache). , que vous pouvez lire ici:
Étapes pour configurer Apache Bench (AB) sur Windows (IMO - Recommandé).
Étape 1 - Installez Xampp.
Étape 2 - Ouvrez le CMD.
Étape 3 - Accédez à la destination du banc d’Apache (cd C:\xampp\Apache\bin) à partir de CMD
Étape 4 - Collez la commande (ab -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://localhost:yourport/)
Étape 5 - Attendez-le. Tu es fini
Charger en charge votre API en utilisant simplement ab n'est pas suffisant. Cependant, je pense que c'est un excellent outil pour vous donner une idée de base de la performance de votre site.
Si vous souhaitez utiliser la commande ab pour tester plusieurs points de terminaison d'API, avec des données différentes, tous en même temps en arrière-plan, vous devez utiliser la commande "Nohup". Il exécute n'importe quelle commande même lorsque vous fermez le terminal.
J'ai écrit un script simple qui automatise l'ensemble du processus, n'hésitez pas à l'utiliser: http://blog.ikvasnica.com/entry/load-test-multiple-api-endpoints-concurrently-use-this-simple-Shell -script
Je me demandais aussi si je pouvais mesurer la vitesse de mon script avec Apache abs ou un script de mesure de construction/destruction de php ou une extension php.
les deux derniers ont échoué pour moi: ils sont approximatifs… .. après quoi j'ai pensé essayer «ab» et «abs».
la commande "ab -k -c 350 -n 20000 example.com/" est belle car tout est plus simple!
mais est-ce que quelqu'un a pensé à "localhost" sur un serveur Apache, par exemple www.apachefriends.org?
vous devez créer un dossier tel que "bench" dans la racine où vous avez 2 fichiers: test "bench.php" et référence "void.php".
et ensuite: le comparer!
bench.php
<?php
for($i=1;$i<50000;$i++){
print ('qwertyuiopasdfghjklzxcvbnm1234567890');
}
?>
void.php
<?php
?>
sur votre bureau, vous devez utiliser un fichier .bat (sous Windows) comme celui-ci:
bench.bat
"c:\xampp\Apache\bin\abs.exe" -n 10000 http://localhost/bench/void.php
"c:\xampp\Apache\bin\abs.exe" -n 10000 http://localhost/bench/bench.php
pause
Maintenant, si vous faites très attention ...
le script vide ne produit pas zéro résultat !!! LA CONCLUSION EST: à partir du deuxième résultat, le premier résultat devrait être diminué !!!
ici j'ai eu:
c:\xampp\htdocs\bench>"c:\xampp\Apache\bin\abs.exe" -n 10000 http://localhost/bench/void.php
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.Apache.org/
Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
Server Software: Apache/2.4.33
Server Hostname: localhost
Server Port: 80
Document Path: /bench/void.php
Document Length: 0 bytes
Concurrency Level: 1
Time taken for tests: 11.219 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 2150000 bytes
HTML transferred: 0 bytes
Requests per second: 891.34 [#/sec] (mean)
Time per request: 1.122 [ms] (mean)
Time per request: 1.122 [ms] (mean, across all concurrent requests)
Transfer rate: 187.15 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.3 0 1
Processing: 0 1 0.9 1 17
Waiting: 0 1 0.9 1 17
Total: 0 1 0.9 1 17
Percentage of the requests served within a certain time (ms)
50% 1
66% 1
75% 1
80% 1
90% 1
95% 2
98% 2
99% 3
100% 17 (longest request)
c:\xampp\htdocs\bench>"c:\xampp\Apache\bin\abs.exe" -n 10000 http://localhost/bench/bench.php
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.Apache.org/
Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
Server Software: Apache/2.4.33
Server Hostname: localhost
Server Port: 80
Document Path: /bench/bench.php
Document Length: 1799964 bytes
Concurrency Level: 1
Time taken for tests: 177.006 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 18001600000 bytes
HTML transferred: 17999640000 bytes
Requests per second: 56.50 [#/sec] (mean)
Time per request: 17.701 [ms] (mean)
Time per request: 17.701 [ms] (mean, across all concurrent requests)
Transfer rate: 99317.00 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.3 0 1
Processing: 12 17 3.2 17 90
Waiting: 0 1 1.1 1 26
Total: 13 18 3.2 18 90
Percentage of the requests served within a certain time (ms)
50% 18
66% 19
75% 19
80% 20
90% 21
95% 22
98% 23
99% 26
100% 90 (longest request)
c:\xampp\htdocs\bench>pause
Press any key to continue . . .
90-17 = 73 le résultat que j'attends!