Quelqu'un peut-il s'il vous plaît me guider à travers le processus de test de chargement de mon site Web à l'aide de l' outil Apache bench (ab )?
Je veux savoir ce qui suit:
Combien de personnes par minute le site peut-il gérer?
Veuillez me guider à travers les commandes que je devrais exécuter pour comprendre cela.
J'ai essayé tous les tutoriels et ils sont déroutants.
Réponses:
L'outil de référence Apache est très basique, et s'il vous donnera une idée solide de certaines performances, c'est une mauvaise idée de ne dépendre de lui que si vous prévoyez d'exposer votre site à un stress important en production.
Cela dit, voici les paramètres les plus courants et les plus simples:
-c: ("Concurrence"). Indique le nombre de clients (personnes / utilisateurs) qui accèderont au site en même temps. Pendant les abcourses, des -cclients arriveront sur le site. C'est ce qui décide en fait de la quantité de stress que votre site subira pendant le benchmark.
-n: Indique le nombre de demandes qui vont être effectuées. Cela décide simplement de la longueur du benchmark. Une -nvaleur élevée avec une -cvaleur que votre serveur peut supporter est une bonne idée pour s'assurer que les choses ne se cassent pas sous un stress soutenu: ce n'est pas la même chose de supporter le stress pendant 5 secondes que pendant 5 heures.
-k: C'est ce que font les navigateurs de fonctionnalité "KeepAlive" par nature. Vous n'avez pas besoin de passer une valeur -kcar elle est "booléenne" (ce qui signifie: cela indique 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 que vous voudrez probablement simuler le stress et le flux que votre site aura à partir des navigateurs, il est recommandé de faire un test de performance avec cela.
Le dernier argument est simplement l'hôte. Par défaut, il atteindra 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 accéderez à 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 le processus terminé les 20 000 demandes, vous recevrez des commentaires sur les statistiques. Cela vous dira dans quelle mesure le site a fonctionné sous le stress que vous lui mettez en utilisant les 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 (moyens, temps de réponse minimum et maximum, demandes échouées, 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 des valeurs -c différentes jusqu'à ce que vous atteigniez l'endroit où vous dites "Si je l'augmente, il commence à recevoir des demandes échouées et il se brise".
En fonction de 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, pensez-y de cette façon: si votre utilisateur moyen va répondre à 5 requêtes 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 requêtes, ce qui signifie seulement 1/6 du temps, il arrivera sur le site. Cela signifie également que si vous avez 6 utilisateurs qui accèdent simultanément au site avec ab, vous aurez probablement 36 utilisateurs en simulation, même si votre niveau de concurrence (-c) n'est que de 6.
Cela dépend du comportement que vous attendez de vos utilisateurs utilisant le site, mais vous pouvez l'obtenir à partir de "Je m'attends à ce que mon utilisateur atteigne X requêtes par minute et je considère un temps de réponse moyen 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 maximum et stddev sont toujours valides) et voyez combien vous pouvez faire -c.
J'espère avoir expliqué cela clairement :) Bonne chance
-loption si la page a un contenu dynamique, de cette façon vous n'obtiendrez pas un tas de demandes échouées en raison de la longueur du contenu étant différente entre les demandes.
Veuillez me guider à travers les commandes que je devrais exécuter pour comprendre cela.
Le test le plus simple que vous puissiez faire est d'exécuter 1000 requêtes, 10 à la fois (ce qui simule approximativement 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 à faire.
-c 10 indique à AB de faire 10 demandes à la fois, au lieu d'1 demande à la fois, pour mieux simuler les visiteurs simultanés (par rapport aux visiteurs séquentiels).
-k envoie le KeepAlive tête, qui demande au serveur Web de ne pas arrêter la connexion après chaque requête, mais de continuer à la réutiliser.
J'envoie également l'en-tête supplémentaire Accept-Encoding: gzip, deflateJ'envoie car mod_deflate est presque toujours utilisé pour compresser la sortie texte / html 25% -75% - dont les effets ne doivent pas être ignorés en raison de son 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 simple, ignorez tout MAIS cette ligne:
Requests per second: 704.23 [#/sec] (mean)
Multipliez cela par 60, et vous avez vos demandes par minute.
Pour obtenir des résultats réels, vous voudrez tester Wordpress au lieu d'un fichier HTML statique ou index.php car vous devez savoir comment tout fonctionne ensemble: y compris du code PHP complexe 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 environnement WAMP (j'utilise WampDeveloper, mais il y a 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, il y a un certain nombre de choses que vous pouvez faire pour améliorer les performances globales (requêtes par seconde), et également rendre le serveur Web plus stable sous une charge plus élevée (par exemple, augmenter le -net la -ctendance à planter Apache), que vous pouvez lire ici:
Étapes pour configurer Apache Bench (AB) sous Windows (IMO - recommandé).
Étape 1 - Installez Xampp.
Étape 2 - Ouvrez CMD.
Étape 3 - Accédez à la destination du banc 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. Tu es fini
J'étais également curieux de savoir si je pouvais mesurer la vitesse de mon script avec apache abs ou un script de mesure de construction / destruction 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" à la racine où vous avez 2 fichiers: test "bench.php" et référence "void.php".
<?php
for($i=1;$i<50000;$i++){
print ('qwertyuiopasdfghjklzxcvbnm1234567890');
}
?>
<?php
?>
"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 bien attention ...
le script void ne produit aucun résultat !!! DONC LA CONCLUSION EST: à partir du deuxième résultat, le premier résultat devrait être diminué !!!
ici j'ai:
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!
Charger votre API en utilisant simplement ab ne suffit pas. 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, le tout 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