Apache Benchmark – Concurrence et nombre de requêtes

La documentation de référence indique que la simultanéité est le nombre de requêtes effectuées simultanément, tandis que le nombre de requêtes correspond au nombre total de requêtes. Ce que je me demande, si je mets 100 demandes à un niveau de simultanéité de 20, cela signifie-t-il 5 tests de 20 demandes en même temps, ou 100 tests de 20 requêtes en même temps? Je suppose la deuxième option, en raison des exemples de nombres cités ci-dessous.

Je me demande parce que je vois souvent des résultats tels que celui-ci sur certains blogs de test:

Complete requests: 1000000 Failed requests: 2617614 

Cela semble peu plausible, car le nombre de demandes ayant échoué est supérieur au nombre total de demandes.

Edit: le site qui affiche les numéros susmentionnés: http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apachephp

OU pourrait-il continuer d’essayer jusqu’à ce qu’il atteigne un million de succès? Hm …

Cela signifie un seul test avec un total de 100 demandes, en gardant 20 demandes ouvertes à tout moment. Je pense que l’idée fausse que vous avez est que les demandes prennent toutes le même temps, ce qui n’est pratiquement jamais le cas. Au lieu d’émettre des requêtes par lots de 20, ab commence simplement par 20 requêtes et en émet une nouvelle chaque fois qu’une requête existante se termine.

Par exemple, tester avec ab -n 10 -c 3 commencerait par 3 requêtes simultanées:

 [1, 2, 3] 

Disons que # 2 termine en premier, ab le remplace par un quasortingème:

 [1, 4, 3] 

… alors # 1 peut finir, remplacé par un cinquième:

 [5, 4, 3] 

… Alors # 3 termine:

 [5, 4, 6] 

… et ainsi de suite, jusqu’à la demande un total de 10 demandes ont été faites. (Lorsque les requêtes 8, 9 et 10 sont terminées, la concurrence diminue naturellement à 0).

Avoir du sens?

Pour ce qui est de la question de savoir pourquoi vous voyez des résultats avec plus d’échecs que le nombre total de demandes, je ne connais pas la réponse à cette question. Je ne peux pas dire que j’ai vu ça. Pouvez-vous poster des liens ou des cas de test qui montrent cela?

Mise à jour: En regardant la source , ab suit quatre types d’erreurs qui sont détaillés sous la ligne “Demandes ayant échoué: …”:

  • Connect – ( err_conn in source) Incrémenté lorsque ab ne parvient pas à configurer la connexion HTTP
  • Receive – ( err_recv dans la source) Incrémenté lorsque ab échoue, une lecture de la connexion échoue
  • Length – ( err_length in source) Incrémenté lorsque la longueur de la réponse est différente de la longueur de la première bonne réponse reçue.
  • Exceptions – ( err_except in source) Incrémenté lorsque ab voit une erreur lors de l’interrogation du socket de connexion (par exemple, la connexion est supprimée par le serveur?)

La logique entourant le moment où ceux-ci se produisent et comment ils sont comptés (et comment le nombre total de bad est suivi) est nécessairement complexe. Il semble que la version actuelle de ab ne compte qu’une fois par échec, mais l’auteur de cet article utilisait peut-être une version antérieure qui en comptait plus d’une. C’est ma meilleure supposition.

Si vous êtes capable de reproduire le comportement, déposez définitivement un bogue .

Je ne vois rien de mal. Les demandes ayant échoué peuvent incrémenter plus d’une erreur chacune. C’est comme ça que ça fonctionne.

Il existe plusieurs tampons statiquement déclarés de longueur fixe. Combiné à l’parsing paresseuse des arguments de la ligne de commande, aux en-têtes de réponse du serveur et à d’autres entrées externes, cela pourrait vous affecter.

Vous remarquerez peut-être par exemple que les résultats des nœuds précédents ont un nombre similaire pour 3 des compteurs d’erreurs. Très probablement, sur les 100 000 demandes faites, 8409 seulement ont échoué et non 25227.

 Receive: 8409, Length: 8409, Exceptions: 8409