Comment suis-je censé interpréter les résultats de l'outil d'évaluation ab d'Apache ?

Question

J'ai cherché partout et je n'ai pas trouvé de ressource détaillée en ligne sur la façon d'interpréter les résultats de l'outil d'évaluation des performances du serveur ab d'Apache. J'ai effectué plusieurs tests avec ce que je pensais être des paramètres radicalement différents, mais j'ai vu des résultats très similaires (j'ai du mal à penser que cela signifie que mon site est parfaitement mis à l'échelle !) Si quelqu'un peut m'indiquer une ressource détaillée sur la façon de comprendre les résultats de ce test, ou si quelqu'un a envie d'en créer une ici, je pense que ce serait très utile pour moi et pour d'autres.

Answer 1

C'est frustrant, n'est-ce pas ? J'essaie de faire la même chose, voir comment mon serveur dédié nouvellement provisionné et configuré se compare aux autres.

Ce que je finis par faire est de comparer mon serveur de production actuel (Dual core 4GB RAM) au nouveau serveur (Quad core 8GB RAM).

J'ai besoin de "jouer gentiment" avec mes comparaisons côte à côte, car le serveur de production est opérationnel et je ne veux pas "casser" le serveur pour mes utilisateurs.

Comparer l'actuel et le nouveau avec la commande suivante sur une page php qui appelle simplement phpinfo() : ab -kc 20 -t 60

Sur mon serveur de production actuel, je vois quelque chose comme ce qui suit, où il n'a pas pu accomplir la tâche dans le temps imparti :

Time taken for tests:   60.1234 seconds
Complete requests:  24538
Failed requests:    58
(Connect: 0, Length:    58, Exceptions: 0)
Requests per second:    408.96 [#/sec] (mean)
Time per request:   48.905 [ms] (mean)
Time per request:   2.445 [ms] (mean, across all concurrent requests)

VS ce qui suit sur le nouveau serveur qui a effectué tous les tests en deux fois moins de temps :

Time taken for tests:   29.838791 seconds
Complete requests:  50000
Failed requests:    11
(Connect: 0, Length:    11, Exceptions: 0)
Requests per second:    1675.67 [#/sec] (mean)
Time per request:   11.936 [ms] (mean)
Time per request:   0.597 [ms] (mean, across all concurrent requests)

Ce n'est pas vraiment un test "équitable", car le serveur actuel gère 20 sites web en plus du test de référence. De plus, il ne teste qu'apache et php.

En effectuant ce même test sur l'une de mes pages d'accueil les plus complexes, une page qui semble lente sur le serveur actuel, j'obtiens les résultats suivants : Serveur actuel :

Time taken for tests:   60.14170 seconds
Complete requests:  510
Requests per second:    8.50 [#/sec] (mean)
Time per request:   2353.497 [ms] (mean)
Time per request:   117.675 [ms] (mean, across all concurrent requests)

Nouveau serveur :

Time taken for tests:   60.18651 seconds
Complete requests:  1974
Requests per second:    32.89 [#/sec] (mean)
Time per request:   608.092 [ms] (mean)
Time per request:   30.405 [ms] (mean, across all concurrent requests)

Ce test charge une page générée dynamiquement par Joomla CMS. C'est un peu plus un test du "monde réel". Encore une fois, le nouveau serveur n'a pas à faire face au trafic actuel du site, ce n'est donc pas une comparaison de pommes à pommes. Je ne veux pas faire de tests plus poussés, sinon je risque de compromettre l'expérience de mes utilisateurs finaux sur mes sites.

Après avoir migré les sites vers le nouveau serveur, j'ai l'intention de refaire les tests ci-dessus afin de voir quel est l'effet du trafic régulier de mon site sur l'analyse comparative. Les résultats des tests de production et de repos de la même machine.

Maintenant, je cherche également à stresser le nouveau serveur et à m'assurer qu'il réagit bien. En exécutant la commande ab -n 50000 -c 200 Je regarde le top et voir combien de CPU et de mémoire sont utilisés tout en * f5 *Je consulte la page dans mon navigateur pour voir s'il y a des erreurs et aussi pour avoir une idée du temps que met le serveur à répondre.

Mon premier test m'a donné :

Concurrency Level:  200
Time taken for tests:   692.160011 seconds
Complete requests:  50000
Failed requests:    30102
(Connect: 0, Length:    30102, Exceptions: 0)
Write errors:   0
Non-2xx responses:  30102
Total transferred:  456568770 bytes
HTML transferred:   442928962 bytes
Requests per second:    72.24 [#/sec] (mean)
Time per request:   2768.640 [ms] (mean)
Time per request:   13.843 [ms] (mean, across all concurrent requests)
Transfer rate:  644.17 [Kbytes/sec] received

Notez le taux d'échec très élevé des requêtes. Mon Apache est réglé sur un maximum de 250 requêtes simultanées, mais mon MySQL n'était qu'à 175. MySQL était le point de défaillance ici. Il ne pouvait pas traiter toutes les demandes provenant d'Apache. Les chargements de pages de mon navigateur Web me donnaient une page d'erreur de connexion MySQL lors de nombreux rafraîchissements de page.

J'ai donc fait passer MySQL à 300 requêtes simultanées (je l'avais déjà fait, mais j'avais oublié de redémarrer MySQL, donc cela s'est avéré être un bon test - j'avais identifié un changement nécessaire, et j'ai accidentellement fait un test empirique validant la nécessité du changement).

L'exécution suivante m'a donné les résultats suivants :

Concurrency Level:      200
Time taken for tests:   1399.999463 seconds
Complete requests:      50000
Failed requests:        5054
   (Connect: 0, Length: 5054, Exceptions: 0)
Write errors:           0
Non-2xx responses:      5054
Total transferred:      1016767290 bytes
HTML transferred:       995713274 bytes
Requests per second:    35.71 [#/sec] (mean)
Time per request:       5599.998 [ms] (mean)
Time per request:       28.000 [ms] (mean, across all concurrent requests)
Transfer rate:          709.24 [Kbytes/sec] received

Cela a pris deux fois plus de temps, mais le taux d'échec des demandes était beaucoup plus faible. En gros, le serveur est maintenant configuré pour pouvoir gérer au moins 200 consultations simultanées de la page d'accueil d'un de mes sites, mais il faut 5 secondes par page pour les servir. Ce n'est pas génial, mais c'est beaucoup mieux que les erreurs MySQL que je recevais auparavant.

Pendant tout ce temps, l'utilisation de l'unité centrale de mon serveur est de 100 % et la "charge moyenne" est de 180 %. MySQL utilise environ 8 à 9 % de l'unité centrale et n'utilise pas beaucoup de la RAM que je lui ai allouée, car je ne fais que marteler la même page de façon répétée, et il ne s'occupe donc que d'une seule base de données. 400MB des 4GB+ qu'il est configuré pour prendre en charge. top montre que l'utilisation des tampons et de la mémoire cache représente environ 50 % de la RAM totale disponible. Ainsi, bien que je charge la machine avec ce test, elle ne s'approche pas du point de surcharge. Dans le cadre d'une utilisation réelle de la base de données, MySQL devrait utiliser la majeure partie de la mémoire que je lui ai allouée, et le serveur devrait donc être proche de la pleine charge à ce stade.

Le test suivant consistait à tester Apache à la "pleine charge" de 250 connexions. ab -n 50000 -c 250

Concurrency Level:      250
Time taken for tests:   1442.515514 seconds
Complete requests:      50000
Failed requests:        3509
   (Connect: 0, Length: 3509, Exceptions: 0)
Write errors:           0
Non-2xx responses:      3509
Total transferred:      1051321215 bytes
HTML transferred:       1029809879 bytes
Requests per second:    34.66 [#/sec] (mean)
Time per request:       7212.577 [ms] (mean)
Time per request:       28.850 [ms] (mean, across all concurrent requests)
Transfer rate:          711.73 [Kbytes/sec] received

Les résultats sont similaires à ceux du test de 200 connexions avec le plafond de connexion MySQL approprié. Je pense que c'est bon pour moi. Je n'aime pas les 7 secondes pour retourner une page, mais je pense que je peux améliorer cela au niveau de Joomla en activant la mise en cache dans Joomla soit avec APC ou Memcache qui sont tous deux installés mais pas encore utilisés par Joomla.

Pour tenter de pousser ma chance, je me suis dit que j'allais essayer 300 connexions simultanées. ab -n 50000 -c 300 Le navigateur affiche une longue attente pour un chargement rapide de la page. Sinon, il n'y a pas vraiment de changement dans les résultats.

Concurrency Level:      300
Time taken for tests:   1478.35890 seconds
Complete requests:      50000
Failed requests:        2266
   (Connect: 0, Length: 2266, Exceptions: 0)
Write errors:           0
Non-2xx responses:      2266
Total transferred:      1079120910 bytes
HTML transferred:       1057241646 bytes
Requests per second:    33.83 [#/sec] (mean)
Time per request:       8868.215 [ms] (mean)
Time per request:       29.561 [ms] (mean, across all concurrent requests)
Transfer rate:          712.99 [Kbytes/sec] received

Je ne sais pas si mon interprétation de ces résultats est "juste" ou si je manque quelque chose de valable, mais avec le manque d'instructions que j'ai pu trouver, voici ce que j'ai trouvé.

J'ai juste utilisé les résultats pour m'assurer que j'avais un bon taux de réponse - l'absence d'un taux de réponse parfait me préoccupe, mais je ne sais pas comment voir ou reproduire les échecs de manière à pouvoir les inspecter.

La lenteur des requêtes me préoccupe également, mais je pense pouvoir y remédier en grande partie au niveau de la couche applicative.

Je suis persuadé que le serveur, même s'il ralentirait à vue d'œil, pourrait supporter une charge importante.

L'examen d'autres outils d'optimisation des performances, comme MonYog, après ces tests d'évaluation comparative, m'a également montré que mes configurations actuelles sont "suffisantes".

J'aimerais qu'il y ait un endroit où les gens ont posté des résultats de tests que je peux reproduire avec une description du matériel et des configurations logicielles afin que je sache si je suis "compétitif" ou si j'ai encore beaucoup de travail à faire pour utiliser au mieux mon équipement. C'est pourquoi je publie mes résultats.

Answer 2

Veuillez noter que pour la ligne "demandes échouées", une demande échouée est déterminée en comparant la longueur des demandes subséquentes entre elles. Pour un site web dynamique, cela ne signifie pas nécessairement que la demande a échoué ! Ne vous inquiétez donc pas de la ligne "échec de la demande".

Voir aussi : http://www.celebrazio.net/tech/unix/apache_bench.html

Answer 3

En plus de la réponse de Creuzerm. Voici un très bon lien avec de plus amples informations.

http://serverfault.com/questions/274252/apache-ab-please-explain-the-output

Pour en savoir plus sur la différence entre les lignes

Time per request:       7.303 [ms] (mean)
Time per request:       0.730 [ms] (mean, across all concurrent requests)

Answer 4

Par ailleurs, AB est un logiciel monofilaire (ce qui est acceptable pour les vieux processeurs à un seul cœur comme le Pentium 4 de 2001).

Pour tester un CPU multi-core hébergeant un serveur Web (Nginx/Lighty utilisant plusieurs processus, Apache utilisant plusieurs threads), vous devez plutôt utiliser Weighttp (qui est compatible avec AB).

"Weighttp -t 6" exécutera 6 threads clients (par contraste "AB -t 6" exécuterait un test de 6 secondes).

Vous obtiendrez des résultats beaucoup plus pertinents en utilisant plusieurs threads clients (autant que le nombre de travailleurs du serveur Web - qui devrait correspondre au nombre de cœurs de processeur du boîtier serveur).

Answer 5

Time per request:       7.303 [ms] (mean)
Time per request:       0.730 [ms] (mean, across all concurrent requests)

le premier est lié au temps moyen de la demande par utilisateurs simultanés, donc si vous faites le test pour 1000 demandes et 200 utilisateurs simultanés, le premier sera le temps moyen pour chaque 200 demandes. le second est lié au temps global de la demande qui est le temps moyen sur l'ensemble des 1000 demandes.