Qui obtient les bonnes mesures, JMeter ou Apache ab?

Jmeter vous indique combien de temps chaque requête a réellement pris. AB fait juste quelques calculs très basiques pour obtenir la moyenne globale. Donc, la réponse directe à votre question Est que jmeter a raison et ab fait juste une estimation approximative en vous donnant la moyenne à travers tout.

Mais, bien sûr, si vous mettez les deux outils côte à côte et que vous les évaluez pour la vitesse, il est clair que ab va effectuer jmeter. Jmeter fait juste plus, il enregistre plus de données et traite plus logique donc il faut plus de temps pour tourner autour d'une seule requête. Le simple fait est que Jmeter est un outil de test de charge complet, AB est, bien, pas.

Le fait est que le but d'un outilload testing n'est pas d'être l'enfant le plus rapide du bloc, mais plutôt de pouvoir construire une représentation réaliste du type de charge avec laquelle votre application pourrait être touchée quand elle sera mise en ligne. À cet égard, jmeter gagne haut la main, donc cela dépend vraiment de vos besoins. Si vous voulez juste pour générer autant de requêtes que possible en utilisant le moins de matériel, ab est un bon choix, mais si vous voulez construire un test représentatif, avec des trajets transactionnels, une logique conditionnelle et toutes sortes d'autres choses utiles, alors jmeter est le chemin à parcourir. Pensez-y comme ceci: ils sont tous deux des projets Apache mais AB a été, je pense, conçu pour tester le serveur web apache, JMeter, cependant, a été conçu pour tester Tomcat.

Maintenant, je suppose que jmeter produisait des résultats incohérents parce qu'il frappait une limite sur la machine sur laquelle il fonctionnait. Je parie que vous couriez en mode GUI et que vous aviez au moins un écouteur actif, comme ceci, vous demandez à l'outil de faire beaucoup. Si vous avez besoin d'un taux élevé de demandes, Jmeter a un mode lean et mean. En règle générale, pour les gros volumes, la meilleure pratique consiste à exécuter des tests en ligne de commande avec très peu d'auditeurs; il y a beaucoup d'informations sur ce sujet sur le site apache jmeter.

Un autre point que vous devriez considérer, si vous êtes vraiment en train de tester la charge, c'est que pour vraiment profiter de ce genre de chose, vous devez d'abord décider quel type de charge vous avez besoin de votre site pour soutenir et seulement alors vous devriez concevoir un test qui représente cela. Ceci est réalisé en utilisant le rythme et les temps d'attente simulés. Le problème avec le fait de dire à un thread qui devrait simplement disparaître et courir aussi vite qu'il le peut, c'est qu'il itérera aussi vite que ses conditions locales le permettent, mais il y aura toujours {[8] } quelque chose qui met les pauses, même ab est limité; peu importe la légèreté d'un outil, il fait toujours quelque chose. Mais si vous accélérez vos requêtes, vous supprimez ce problème et, comme un bonus supplémentaire plutôt utile, vous vous retrouvez avec une cohérence entre les exécutions et entre les builds du code, donc même si votre serveur accélère ou ralentit (avec des modifications de la base de code) votre test fera toujours le même taux de requêtes - ce qui est très utile pour

Si vous voulez prendre JMeter plus loin, jetez un oeil à la minuterie de débit Constant, puis utilisez plusieurs threads pour construire le niveau de trafic que vous devez représenter.