Test de charge avec AB… fausses demandes ayant échoué (longueur)

209

Pour faire des tests de charge, pour ma propre curiosité, sur mon serveur, j'ai couru:

ab -kc 50 -t 200 http://localhost/index.php

Cela ouvre 50 connexions persistantes pendant 200 secondes et claque simplement mon serveur avec des demandes d'index.php

Dans mes résultats, j'obtiens:

Concurrency Level:      50
Time taken for tests:   200.007 seconds
Complete requests:      33106
Failed requests:        32951
   (Connect: 0, Receive: 0, Length: 32951, Exceptions: 0)
Write errors:           0
Keep-Alive requests:    0
Total transferred:      1948268960 bytes
HTML transferred:       1938001392 bytes
Requests per second:    165.52 [#/sec] (mean)
Time per request:       302.071 [ms] (mean)
Time per request:       6.041 [ms] (mean, across all concurrent requests)
Transfer rate:          9512.69 [Kbytes/sec] received

Notez les 32951 demandes "échouées". Je ne peux pas comprendre cela.

Pendant que le test était en cours, j'ai pu accéder parfaitement à mon site Web à partir de mon ordinateur à la maison, bien que les temps de chargement des pages au bas de la page aient été signalés comme 0,5 au lieu de 0,02 habituel. Cependant, je n'ai jamais eu une seule fois échoué.

Alors pourquoi AB signale-t-il que la moitié des connexions échouent? Et que signifie "Longueur:" dans ce contexte?

benchmarking load-testing apachebench

— Benjamin
source

Votre site Web a-t-il un équilibreur de charge? Voir mon article de blog sur les tests de charge avec les équilibreurs de charge qui pourrait expliquer la situation "ça marche pour moi" dans les tests de charge.

— Patrick Lightbody

Réponses:

361

Ça ne fait rien. L '"échec de longueur" indique simplement qu'environ la moitié du temps, la longueur de la réponse était différente.

Puisque le contenu est dynamique, c'est probablement l'identifiant de session ou quelque chose comme ça.

— Jeff Atwood
source

Hé, je viens de rencontrer le même "problème" et je suis content que cette réponse soit là. Merci!

— Richard Hurt

Merci pour la réponse, j'avais exactement le même doute.

— Saiyine

Oui, deux ans plus tard, cette réponse est toujours très utile.

— Sergi

Ne soyez pas trop rapide pour attribuer cela à des différences de longueur de contenu variable. ab ne signale pas le code d'état HTTP 500 comme des erreurs dans son résumé. La raison de la non-concordance de longueur peut être que vous avez une véritable erreur. Vous pouvez utiliser -v 4 pour obtenir plus d'informations (mieux diriger vers un fichier car il y aura beaucoup d'impressions).

— Tal Lev-Ami

En fait, cela est expliqué dans le manuel ab ici httpd.apache.org/docs/current/programs/ab.html "Si la longueur du document change pendant le test, la réponse est considérée comme une erreur."

— Захар Joe

132

Pour décrire le problème en d'autres termes:

L'outil d'analyse comparative d'Apache (ab) suppose que la longueur du contenu de la réponse sera la même pendant tout le test. Il stocke la longueur du contenu de la première réponse. Si l'une des autres réponses a une longueur de contenu différente, elle entraîne des «échecs de longueur».

Le rapport de bogue apache suivant semble confirmer que: bogue ASF 42040

Résumé : Si vous diffusez un contenu de longueur variable, vous devez probablement ignorer ce type d'échecs de demande d'ab.

Edit : J'ai récemment remarqué que la abcommande a une nouvelle option (au moins pour moi):

-l   Accept variable document length (use this for dynamic pages)

Je peux le voir dans une version 2.3 <$ Revision: 1528965 $> mais je ne peux pas le voir dans une version 2.3 <$ Revision: 655654 $> , donc il a probablement été ajouté relativement récemment.

— Dariusz Walczak
source

Pour n'importe qui sur Mac, il y a de fortes chances que votre version de ab soit derrière et -l ne le prenne pas. Vous pouvez installer à partir des sources ou via homebrew, mais "brew install ab" ne fonctionne pas car il fait partie du paquet apache - vous pouvez installer avec "brew install homebrew / apache / ab".

— netpoetica

Désolé de ressusciter une vieille question, mais c'était la première qui apparaissait dans Google. Parfois, l'erreur de longueur signalée par ab peut être due à un problème réel: si la connexion est fermée côté serveur avant que le nombre total d'octets déclarés dans l'en-tête Content-Length n'ait été reçu par le client. Cela peut se produire s'il y a d'autres parties entre le client et le serveur, par exemple, des équilibreurs de charge artisanaux naïfs (mon cas).

— zentrunix
source