new Blog( perso );

Je passe l'été en compagnie de jMeter, parce que la plage c'est ringard et qu'on y prend des coups de soleil.

jMeter est un outil bien rodé, mais qui cache tout de même mal son âge. Si on pardonne l'IHM Swing assez moche, la logique de manipulation des éléments de contrôle est assez étrange. En particulier, les temps d'attente qu'il faut attacher en fils pour qu'ils s'exécutent avant une requête, plutôt que de les mettre ... avant elle, c'est assez tordu. Ceci dit, une fois qu'on a pigé le truc on arrive à s'y faire (« c'est pas pire que de passer à Maven » diraient certains).

Si on regarde sous le capot, là aussi ça sent fort le old school, jMeter date tout de même de 1998 (regardez le code de vos projets de 1998 pour rigoler). Il y a clairement une dette technique sur ce projet, même si ça ne l'empêche pas de rester pertinent. Pour ma part j'ai du développer un Sampler qui récupère les métriques JMX (java.lang:type=Memory) de la JVM sous charge, ainsi qu'un Listener qui stocke les mesures brutes dans une base Derby plutôt qu'un fichier CSV (données plus faciles à exploiter par la suite avec BIRT par exemple, voir ici). Ca se fait sans grande difficulté, mais c'est pas du code magnifiquement découpé comme on en fait tous aujourd'hui (ah bon, pas vous ? :P)

Une astuce à connaître : Quand on capture un scénario avec le proxy HTTP, on peut regrouper toutes les requêtes liées à un clic sous un contrôleur, ce qui clarifie le scénario. En remplaçant ces contrôleurs "génériques" par des "Transaction Controller" (et là on est bien content que le script soit en XML) on obtient une métrique pour chaque page de l'appli web, ce qui reflète mieux la performance ressentie par l'utilisateur que les résultats HTTP bruts.

Gros gros bémol à l'utilisation de jMeter : le reporting en est quasiment absent, et on est donc obligé d'exporter les données brutes en CSV (ou en base dans mon cas) pour une consolidation externe. D'un autre côté, quand on voit les tarifs de LoadRunner ou même de NeoLoad, on se dit que c'est l'occasion de s'essayer au reporting BIRT...

Autre soucis : jMeter utilise un Thread par utilisateur virtuel. C'est nettement plus simple pour son implémentation interne, mais pour simuler des milliers d'utilisateurs, même si chacun ne fait qu'une requête par minute, ça pose de gros soucis : chaque Thread occupe de la mémoire (native+heap) et on est vite à cours de ressources, sans parler de la surcharge pour l'OS qui doit gérer en masse les changements de contexte de ces Threads, qui ne font pourtant pas grand chose. Je me lancerais bien dans un gros refactoring de jMeter mais ... euh ... bon, vous aurez compris.

Ceci dit, la question est de savoir ce qu'on désire faire avec jMeter. Dans un esprit "consulting", on lui demande de valider une SLA et de fournir de jolis graphes 3D pour mettre dans le joli rapport d'audit en couleur sous Office 2010. Dans un esprit "main dans le cambouis" on lui demande de charger l'appli qu'on aura mis préalablement sous monitoring / profiling pour en déceler les faiblesses et y remédier. Ce n'est donc pas un hasard si jMeter supporte une dizaine de protocoles, mais sort péniblement un graphe tout moche : il a choisit son camp.

En tout cas, et jusqu'à preuve du contraire, jMeter est le seul outil à se greffer facilement dans une intégration continue pour faire de l'analyse d'évolution de perf, ce qui est nettement mieux que d'attendre la pré-prod pour tester l'appli et se rendre compte d'un gros problème de conception ...