Les tests de charge

Question

Je suis confus.

Quelqu'un peut-il me guider s'il vous plaît dans le processus de comment je peux charger tester mon site web en utilisant 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.

Answer 1

L'apache outil de benchmark est très basique, et alors qu'il va vous donner une idée solide de certaines performances, c'est une mauvaise idée de ne dépendent que si vous prévoyez d'avoir votre site exposé à de graves problèmes dans la production.

Cela dit, voici la plus courante et la plus simple des paramètres:

-c: Indique le nombre de clients (les gens) seront frapper le site en même temps. Cela signifie "simultanéité". À tout moment l'exécution de l'outil, il y aura-c les clients visitent le site. C'est ce qui décide de la quantité de stress à votre site de souffrir lors de l'indice de référence.

-n: indique le nombre de demandes vont être effectuées sur le site. Cette simplement décider de la longueur de l'indice de référence. À haute valeur n avec a-c de la valeur que votre serveur peut prendre en charge est une bonne idée de s'assurer que les choses ne se cassent pas sous un stress soutenu: ce n'est pas la même à l'appui de stress pendant 5 secondes que pour les 5 heures.

-k: C'est "KeepAlive" fonctionnalité des navigateurs le font par nature. Vous n'avez pas besoin de passer une valeur de k comme lui qu'il "boolean" (ce qui signifie: il indique que vous désirez pour votre test de l'utilisation de la Garder Vivante en-tête de HTTP et de maintenir la connexion). Depuis que les navigateurs ce faire, et vous êtes susceptible de vouloir simuler le stress et les flux de votre site à partir de navigateurs, il est recommandé de faire un test avec cette.

Le dernier argument est tout simplement l'hôte. Par défaut, il sera frappé http:// protocole si vous ne spécifiez pas.

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

En émettant la commande ci-dessus, vous serez frappé http://mysite.com/ 350 connexions simultanées jusqu'à 20 mille demandes sont satisfaites. Il sera fait à l'aide de la garder en vie d'en-tête.

Une fois le processus terminé le 20 mille demandes, vous recevrez des conseils sur les stats. Cela vous dira comment bien le site réalisé sous le stress lorsque vous utilisez les paramètres ci-dessus.

Pour savoir combien de personnes le site peut gérer en même temps, il suffit de voir si le temps de réponse (ce qui signifie, min et max temps de réponse, des demandes ayant échoué, etc) sont les numéros de votre site peut accepter (différents sites pourraient désir des vitesses différentes). Vous pouvez exécuter l'outil avec différentes valeurs de c jusqu'à ce que vous frappez l'endroit où vous dites: "Si je l'augmenter, il commence à faire les demandes ayant échoué et il se casse".

En fonction de votre site web, vous attendez qu'un nombre moyen de requêtes par minute. Cela varie tellement, vous ne serez pas en mesure de simuler ce avec ab. Cependant, pensez-y de cette façon: Si votre utilisateur moyen va être frapper 5 requêtes par minute et le temps de réponse moyen que vous trouvez valide est de 2 secondes, ce qui signifie que 10 secondes à une minute, 1 utilisateur sera sur demande, de sens que 1/6 du temps, il sera de frapper le site. Cela signifie également que si vous avez 6 utilisateurs en appuyant sur le site avec ab simultanément, vous êtes susceptibles d'avoir 36 utilisateurs de la 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 en utilisant le site, mais vous pouvez obtenir à partir de "j'attends mon utilisateur d'appuyer sur X requêtes par minute, et je considère un temps de réponse moyen valable que si elle est de 2 secondes". Puis il suffit de modifier votre -niveau c jusqu'à ce que vous frapper de 2 secondes de temps de réponse moyen (mais assurez-vous que le max de temps de réponse et écart type est toujours valable) et de voir à quel point vous pouvez faire -c.

J'espère que j'ai expliqué cela soit clair :) Bonne chance

Answer 2

Merci de me promener à travers les commandes je devrais courir pour comprendre cela.

Le test le plus simple que vous pouvez faire est d'effectuer 1000 demandes, 10 à un moment (environ simule 10 utilisateurs simultanés obtenir 100 pages chacun - au cours de la durée de l'essai).

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 raconte AB de faire 10 demandes à la fois, au lieu de 1 demande, à un moment, pour mieux simuler les visiteurs simultanés (vs séquentielle des visiteurs).

-k envoie l' KeepAlive - tête, qui demande au serveur web de ne pas fermer la connexion après chaque demande est fait, mais au lieu de garder le réutiliser.

Je suis également de l'envoi de l'en-tête supplémentaire Accept-Encoding: gzip, deflate parce que mod_deflate est presque toujours utilisé pour compresser le texte/html de sortie de 25%-75% - dont les effets ne devraient pas être licencié 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 la simple interprétation, ignorent tout, MAIS cette ligne:

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

Multiplier par 60, et vous avez vos demandes par minute.

Pour obtenir les résultats réels, vous aurez envie de tester Wordpress au lieu de certains de HTML statique ou index.php fichier parce que vous avez besoin de savoir comment tout exécute ensemble: y compris les complexes de code PHP, et de multiples requêtes MySQL...

Par exemple voici les résultats de l'essai d'une nouvelle installation de Wordpress sur le même système et environnement WAMP (je suis en utilisant 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 charge, il ya un certain nombre de choses que vous pouvez faire pour améliorer la performance globale (Requêtes Par Seconde), et également le serveur web plus stable, de plus en plus de la charge (par exemple, l'augmentation de l' -n et de la -c a tendance à planter Apache), que vous pouvez lire ici:

Le Test de charge Apache avec AB (Apache Bench)