ab test de charge

L’outil de référence Apache est très basique et, bien qu’il vous donne une idée précise de certaines performances, il est déconseillé d’en dépendre uniquement si vous souhaitez exposer votre site à de graves problèmes de production.

Cela dit, voici les parameters les plus communs et les plus simples:

-c : (“concurrence”). Indique combien de clients (personnes / utilisateurs) vont atteindre le site en même temps. Pendant que ab court, il y aura des clients -c sur le site. C’est ce qui détermine la quantité de stress que votre site subira au cours de l’évaluation.

-n : indique le nombre de requêtes à effectuer. Cela ne fait que décider de la longueur du benchmark. 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 soutenu: il ne faut pas supporter le stress pendant 5 secondes que pendant 5 heures.

-k : Les navigateurs fonctionnels “KeepAlive” fonctionnent naturellement. Vous n’avez pas besoin de passer une valeur pour -k telle qu’elle est “booléenne” (ce qui signifie que vous souhaitez que votre test utilise l’en-tête Keep Alive de HTTP et maintienne la connexion). Comme les navigateurs le font et que vous êtes susceptible de vouloir simuler le stress et le stream que votre site aura sur les navigateurs, il est recommandé de faire un test de performance avec cela.

L’argument final est simplement l’hôte. Par défaut, il basha le protocole http: // si vous ne le spécifiez pas.

 ab -k -c 350 -n 20000 example.com/ 

En lançant la commande ci-dessus, vous atteindrez http://example.com/ avec 350 connexions simultanées jusqu’à ce que 20 000 requêtes soient satisfaites. Cela se fera en utilisant l’en-tête keep alive.

Une fois le processus terminé, vous recevrez des commentaires sur les statistiques. Cela vous dira comment le site s’est bien comporté sous le stress que vous avez mis en utilisant les parameters ci-dessus.

Pour savoir combien de personnes le site peut gérer en même temps, vérifiez simplement si les temps de réponse (moyennes, temps de réponse min et max, 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, il commence à recevoir des demandes ayant échoué et il se casse”.

Selon votre site Web, vous vous attendez à un nombre moyen de demandes par minute. Cela varie beaucoup, vous ne pourrez pas le simuler avec ab. Cependant, pensez-y de cette manière: si votre utilisateur moyen atteindra 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 par minute, 1 utilisateur sera sur demande, ce qui signifie seulement 1/6 du temps, il sera sur le site. Cela signifie également que si 6 utilisateurs frappent le site simultanément avec ab, vous avez probablement 36 utilisateurs en simulation, même si votre niveau de concurrence (-c) est 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 qu’un temps de réponse moyen 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 est toujours valide) et voyez quelle taille vous pouvez faire -c.

J’espère que j’ai expliqué ce clair 🙂 Bonne chance

Veuillez me guider à travers les commandes que je devrais lancer pour comprendre cela.

Le test le plus simple que vous pouvez effectuer consiste à exécuter 1000 requêtes, 10 à la fois (ce qui simule approximativement 10 utilisateurs simultanés et à obtenir 100 pages chacun – sur toute 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 requêtes à effectuer.

-c 10 indique à AB de faire 10 requêtes à la fois, au lieu de 1 demande à la fois, afin de mieux simuler les visiteurs simultanés (vs visiteurs séquentiels).

-k envoie l’en-tête KeepAlive , qui demande au serveur Web de ne pas arrêter la connexion après chaque requête, mais de continuer à le 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% – dont les effets ne doivent pas être ignorés car cela a un impact sur la performance globale du serveur Web (c.-à-d. peut transférer deux fois 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 l’interprétation la plus 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 concrets, vous voudrez tester WordPress au lieu d’un fichier HTML ou index.php statique 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 des tests d’une nouvelle installation de WordPress sur le même système et l’environnement WAMP (j’utilise WampDeveloper, mais il y a aussi Xampp, WampServer et autres) …

 Requests per second: 18.68 [#/sec] (mean) 

C’est 37x plus lent maintenant!

Après le test de chargement, vous pouvez faire un certain nombre de choses pour améliorer les performances globales (Requests Per Second) et rendre le serveur Web plus stable sous une charge plus importante (par exemple, l’augmentation de -n et -c tendance à se bloquer). Apache), que vous pouvez lire ici:

Test de charge Apache avec AB (Apache Bench)

Étapes pour configurer Apache Bench (AB) sur 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 ) 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

Le test de charge de 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 voulez utiliser la commande ab pour tester plusieurs points de terminaison d’API, avec des données différentes, toutes 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