MilamberSpace – JMeter

Un petit billet pour vous inviter à découvrir ce tutoriel de Antonio Gomes Rodrigues, dont le sujet est l’audit de performance d’une application en Java EE.

C’est un tutoriel extrêmement complet qui couvre de nombreux domaines qui sont liées à la performance en général, et plus particulièrement sur une application J2EE.

Le tutoriel couvre les procédures de test (préparation, principaux métrics), le test de charges avec JMeter, et une dernière partie sur l’identification et la correction des problèmes. On a donc ainsi, l’entrée, le plat et le dessert pour optimiser nos applications J2EE.

La section sur l’identification et la correction des problèmes est particulière exhaustive sur les problèmes que l’on peut en effet rencontrer dans une application. Elle sera très utile pour faire une check-list de vérification si un souci arrive sur son application.

Voilà, c’est à mettre dans vos marques-pages.

./

Un billet pour pointer vers cet autre billet de la société Zenika, qui explique le comment-faire un rapport (graphique) de résultats suite à un test JMeter.

Dans le billet pointé, la source de données est le fichier de résultats JMeter au format JTL (donc XML). BIRT sait le lire ‘nativement’. Mais j’ajouterai qu’il est préférable d’avoir un format CSV pour l’enregistrement des données d’un JMeter (plus rapide et plus économe en taille), et que BIRT sait aussi lire du CSV nativement (à condition d’avoir une virgule comme séparateur (et non un point-virgule comme j’ai tendance à le faire dans mes CSV…))

Enfin, tout cela pour dire, que c’est un bon article à suivre, d’autant que cela peut épater les gens de voir que l’on utilise pas le pauvre (mais pratique) Excel ou OpenOffice pour faire ses graphiques, mais un bel outil de génération de rapports / graphiques.

Maintenant, j’aimerai bien pousser plus loin le bouchon avec JMeter/BIRT pour voir si on peut « préparer » des rapports (au sens PDF) avec tableaux et graphiques à partir de données JMeter d’un même test (qui serait exécuté N fois) afin d’avoir un rapport assez complet en quelques minutes après la fin d’un tir. Ce qui semble carrément possible avec BIRT. A suivre…

Je viens de donner un petit coup de jeune au premier tutoriel JMeter de ce blog. Il avait été fait en 2007, avec la version 2.3RC4 de JMeter, avec des captures de l’interface en anglais, tellement la version française était incomplète et erronée.

Aujourd’hui, c’est la version 2.3.4, et son amélioration de la localisation en français. Donc, voici la nouvelle version de ce tutoriel « JMeter : Test de charges d’un site Web, mode d’emploi », qui maintenant a des captures de l’interface en français. J’en ai également profité pour revoir certains textes et/ou explications.

Bon courage dans vos tests !

./

Nous revoilà dans la deuxième partie de ce tutoriel. Pour rappel, nous étions dans la mise en œuvre d’un test de charges, dont les données injectées proviennent directement d’une base de données et ont été récupérées par JMeter, le tout expliqué dans cette partie. Continue reading ‘JMeter : utilisation de l’élément JDBC comme source de données pour un test de charge (partie 2)’ »

Avec la version 2.3.3, JMeter nous propose une amélioration de l’échantillon JDBC, qui permet de récupérer les valeurs de champs d’une requête SQL de type SELECT et de les placer dans des variables JMeter.

D’où l’idée suivante : Pourquoi ne pas utiliser une base de données comme source de données pour un test de charge ?

Tout d’abord les pré-requis :

• Une base de données bien entendu, avec le pilote JDBC approprié, à placer dans Jmeter_Home/lib
• Dans la base de données, une table avec une liste d’éléments (ici j’ai repris mon fichier BOXERS que j’ai inséré en base)

Bon voyons un peu comment faire. Ci-dessous le plan de test à mettre en œuvre :

Il y a deux parties :

• Partie 1 : qui est chargée de récupérer les données de la base de données (objet de ce billet)
• Partie 2 : qui est le test de charge à proprement parlé, et qui est donc chargé de consommer les données (objet du billet suivant) Continue reading ‘JMeter : utilisation de l’élément JDBC comme source de données pour un test de charge (partie 1)’ »

Dans ce billet, j’indique qu’il est possible d’utiliser SQLite pour traiter les données d’un tir de charges par palier (tutoriel ici).

Voici maintenant le mode d’emploi pour utiliser SQLite afin de traiter ses résultats de tir JMeter. Continue reading ‘JMeter : utiliser SQLite pour traiter les résultats d’un test de charges par palier’ »

Après l’exécution d’un tir de charges, il faut faire le rapport de tir avec si possible de beaux tableaux et/ou graphiques. Si vous avez déjà utilisé JMeter (ce que je présuppose) vous savez que les récepteurs de JMeter sont bien pour avoir des tableaux de résultats (en particulier celui du rapport consolidé), mais ils montrent des limites pour faire des tableaux personnalisés ou bien de beaux graphiques « parlants ».

Il se pose aussi la problématique de l’insertion des résultats affichés par les récepteurs de JMeter dans le document Word ou la présentation PowerPoint (ou OpenOffice). La capture d’écran fait un peu trop ‘bricolage’.

En général, il est préférable de récupérer les résultats au format CSV, puis de les traiter dans un tableur comme Excel ou Calc pour faire des tableaux et des graphiques (voir ce tutoriel).

Mais là aussi, on trouve des limites, notamment pour les « gros » tests de charges avec plus de 100 000 lignes de résultats. Les graphiques étant limités à 32 000 points (Excel/Calc) et les feuilles de tableur à 65 000 lignes (Calc / Excel 2000/2003) et 1 million (Excel 2007).

Une solution possible est de développer un programme « moulinette » qui va effectuer un premier traitement sur les données CSV pour réduire ou agréger les données, par exemple en calculant le temps moyen par intervalle de temps (i.e. par minute, par heure, etc.).

Une autre solution est d’utiliser un logiciel de base de données bureautiques comme Access ou Base pour gérer le grand nombre de lignes, voir cet article.

Une autre solution, que je trouve ‘sympa’, pratique et finalement assez simple pour un informaticien, c’est d’utiliser la petite base de données SQLite. Continue reading ‘JMeter et la création du rapport de tir de charges’ »

Dans ce précédent billet, je montrais une façon de fixer l’intervalle de répétition de ses requêtes, c’est-à-dire lancer une requête chaque 10 secondes quelque soit le temps de réponse de la requête.

JMeter permet faire cela « nativement » avec l’élément Compteur de débit constant.

Voici un arbre JMeter mettant en œuvre cet élément :

Continue reading ‘JMeter : Utiliser le compteur de débit constant’ »

Suite à une discussion avec Eudes (merci) sur le groupe JMeter en français, voici une architecture possible (et testée) pour un test distribué avec des injecteurs qui possèdent deux cartes réseaux.

Une carte réseaux est tournée vers le contrôleur, et une autre carte réseaux est tournée vers le serveur à tester. L’avantage de ne pas mélanger les trafics réseaux : celui des requêtes (vers le serveur) et celui de résultats du test (vers le contrôleur).

Donc voici la recette : Continue reading ‘JMeter : faire un test distribué avec des injecteurs à deux cartes réseaux’ »

Voici un billet pour parler des expressions régulières (regexp) avec JMeter. L’élément Extracteur d’expressions régulières est très utile dans les scénario JMeter pour extraire des données de la réponse reçues suite à une requête. Par contre, il n’est pas toujours facile d’avoir (de trouver) la bonne regexp…

J’ai mis quelques heures pour trouver cette regexp qui était nécessaire pour la préparation d’un scénario de test de charges JMeter. J’ai même adapté un petit programme Java/Swing testeur de regexp style Java pour qu’il devienne un programme testeur de regexp Jakarta ORO, celui du JMeter, ceci afin de tester plus vite les différentes regexp.

Commençons, soit le texte de réponse d’une requête HTTP (utilisant en fait SOAP/XML-RPC) suivant :

<ClientBean>
<id>765432</id>
<code>1.87665308</code>
<nom>JAMES BOND</nom>
<statutNumAppel>Inactif</statutNumAppel>
</ClientBean>
<ClientBean>
<id>765432</id>
<code>1.33333333</code>
<nom>LARGO WINCH</nom>
<statutNumAppel>Inactif</statutNumAppel>
</ClientBean>
<ClientBean>
<id>765432</id>
<code>1.87999999</code>
<nom>BENGAMIN GATES</nom>
<statutNumAppel>Actif</statutNumAppel>
</ClientBean>
<ClientBean>
<id>765432</id>
<code>1.23334444</code>
<nom>EMMA PEAL</nom>
<statutNumAppel>Inactif</statutNumAppel>
</ClientBean>

Cette liste est dynamique (on n’a pas toujours 4 éléments, celui ayant le statut d’actif n’est pas toujours à cette position (ici 3ème) et les valeurs bien entendues changent pour chaque requête du test).

Comment faire pour extraire le code « 1.87999999 » correspondant au même ID 765432 pour chaque élément de cette liste, et qui est celui « Actif » ? Le tout avec une expression régulière JMeter ? Continue reading ‘JMeter : Trouver le bon élément dans une liste avec les expressions régulières et en mode ligne unique’ »