Test de charge avec AB ... fausses requêtes échouées (longueur)

Question

Pour faire quelques tests de charge, pour ma propre curiosité, j'ai exécuté sur mon serveur :

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

Cela ouvre 50 connexions "keep-alive" pendant 200 secondes et assomme mon serveur de requêtes pour 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 requêtes "échouées". Je n'arrive pas à comprendre.

Pendant le test, j'ai pu accéder à mon site Web depuis mon ordinateur personnel, mais le temps de chargement des pages en bas de page était de 0,5 au lieu de 0,02 comme d'habitude. Cependant, je n'ai jamais eu une seule requête qui a échoué.

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

Merci

Answer 1

C'est pas grave. Le "défaut de longueur" indique simplement qu'environ la moitié du temps, la longueur de la réponse était différente.

Comme le contenu est dynamique, il s'agit probablement de l'identifiant de la session ou d'un élément similaire.

Answer 2

Pour décrire la question en d'autres termes :

L'outil de benchmarking apache (ab) suppose que la longueur du contenu de la réponse sera la même pendant toute la durée du test. Il enregistre la longueur du contenu de la première réponse. Si l'une des réponses suivantes a une longueur de contenu différente, il en résulte des "échecs de longueur".

Le rapport de bogue d'Apache suivant semble le confirmer : Bogue ASF 42040

Résumé : Si vous servez un contenu de longueur variable, vous devriez probablement ignorer ce type d'échecs de requête ab.

Modifier : J'ai récemment remarqué que le ab a une nouvelle option (du moins pour moi) :

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

Je peux le voir dans ab Version 2.3 <$Revision : 1528965 $> mais ne peut pas le voir dans ab Version 2.3 <$Revision : 655654 $> Il a donc probablement été ajouté relativement récemment.

Answer 3

Désolé de ressusciter une vieille question, mais c'est la première qui est apparue dans Google. Parfois, l'erreur de longueur signalée par ab peut avoir été causée par un vrai problème : si la connexion est fermée côté serveur avant que la quantité totale d'octets déclarée dans l'en-tête Content-Length n'ait été reçue par le client. Cela peut arriver s'il y a d'autres parties entre le client et le serveur, par exemple des équilibreurs de charge naïfs et artisanaux (mon cas).

Answer 4

Mais nous voyons que les requêtes qu'il montre comme ayant échoué sont en fait enregistrées dans le journal des erreurs de nginx. Il s'agit donc bien d'un décalage de longueur ? et le contenu servi est toujours le même de notre côté.