JMeter et la création du rapport de tir de charges

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. Continuer la lecture de JMeter et la création du rapport de tir de charges

JMeter : Utiliser le compteur de débit constant

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 :

Continuer la lecture de JMeter : Utiliser le compteur de débit constant

JMeter : faire un test distribué avec des injecteurs à deux cartes réseaux

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 : Continuer la lecture de JMeter : faire un test distribué avec des injecteurs à deux cartes réseaux

JMeter : Trouver le bon élément dans une liste avec les expressions régulières et en mode ligne unique

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 ? Continuer la lecture de JMeter : Trouver le bon élément dans une liste avec les expressions régulières et en mode ligne unique

JMeter : Think time et ordre d’exécution, « les bons plans »

Un billet inspiré d’une discussion sur le groupe Google JMeter en français (merci Jslave).

Vous avez fait ce plan de test, avec 2 itérations dans la boucle (01 Contrôleur Boucle) :

En pensant avoir l’ordre d’exécution suivant (pour un groupe d’unités à 1-1-1) :

  • 01 Requête Login
    • (1ère itération de boucle)
      • (Compteur de temps fixe : pause 2 sec)
      • 02 Requête A
      • (Compteur de temps fixe : pause 2 sec)
      • 02 Requête B
      • (Compteur de temps fixe : pause 2 sec)
      • 02 Requête C
    • (2ème itération de boucle)
      • (Compteur de temps fixe : pause 2 sec)
      • 02 Requête A
      • (Compteur de temps fixe : pause 2 sec)
      • 02 Requête B
      • (Compteur de temps fixe : pause 2 sec)
      • 02 Requête C
  • 02 Requête Logout

Malheureusement, le plan de test n’aura pas cet ordre d’exécution Continuer la lecture de JMeter : Think time et ordre d’exécution, « les bons plans »

JMeter : suivre un tir de charge en mode non-gui avec le résumé statistique

Dans le billet précédent, j’indiquais qu’il est préférable de lancer un test de charge en utilisant JMeter en mode non-gui afin de préserver les ressources de la machine JMeter.

Cependant en mode d’exécution non-gui, il est frustrant de ne pas « voir ce qui se passe » : est-ce que le tir de charge se passe bien ?, est-ce qu’il n’y a pas d’erreurs ?, y-a-t-il un blocage ?, …

Heureusement pour nous, JMeter a prévu une option qui va nous permettre d’avoir quelques données durant un tir de charges exécuté en mode non-gui.

Il s’agit du « summariser », ce dernier va afficher à intervalle pré-défini les statistiques du test en cours. Continuer la lecture de JMeter : suivre un tir de charge en mode non-gui avec le résumé statistique

JMeter : Pourquoi exécuter son test de charges en mode non-gui (sans interface graphique) ?

JMeter dispose de deux modes de fonctionnement, un mode GUI et un non-GUI, « GUI » signifiant Graphical User Interface, c’est-à-dire un mode de fonctionnement avec une interface graphique utilisateur qui permet de créer, éditer un script et lancer un test de charges et autres choses. Le mode non-GUI ne permet pas de manipuler un script, mais simplement de lancer le script de test de charges.

Pourquoi ce mode non-GUI ? Parce qu’en mode GUI, JMeter peut être gêné par la gestion du ‘graphisme‘ pendant qu’il est en train d’exécuter un test de charges. Et cela peut avoir un impact sur la qualité des résultats du tir.

En effet, sur le poste JMeter, la gestion du mode graphique impacte : Continuer la lecture de JMeter : Pourquoi exécuter son test de charges en mode non-gui (sans interface graphique) ?

[JMeter] Tutoriel sur la génération d’un graphique OpenOffice.org Calc avec les résultats d’un tir de charges

En ce début d’année, voici un tutoriel sur la génération d’un graphique qui présente les résultats d’un tir de charges JMeter, en utilisant le tableur OpenOffice.org Calc.

Ce tutoriel est important, il vient compléter les autres tutoriels de ce site sur JMeter. Ces derniers étant orientés utilisation de JMeter, celui là se rapproche plutôt d’un tutoriel sur OpenOffice.org Calc et la fonctionnalité de Pilote de données (les tableaux croisés dynamiques sous Excel).

Avec ce tutoriel, vous n’avez plus de raison de ne pas bien présenter vos résultats de test de charges !

Bon courage ! clic

./

Enregistrer un scénario Jmeter d’un site en HTTPS via le proxy HTTP

Mise à jour du 14 juillet 2010 : La nouvelle version 2.4 de JMeter permet maintenant d’enregistrer une session de navigation en HTTPS. Le billet ci-dessous est devenu obsolète.

 

Vous devez effectuer un test de charge sur une application accessible seulement en HTTPS (protocole HTTP avec la couche SSL). Pour la préparation du tir de charges, vous pensez évidemment à enregistrer une session de navigation du scénario fonctionnel qui sera utilisée plus tard pour le tir.

Le problème c’est que lorsque vous lancez le mode proxy de JMeter pour enregistrer votre session de navigation, cela ne marche pas (erreur de méthode non implémentée…) ou bien vous avez coché le « attempt HTTPS spoofing » et la aussi vous avez une erreur (java impossible de se connecter).

Voici ce qu’il faut faire pour que tout cela fonctionne, c’est-à-dire que vous puissiez enregistrer une session de navigation sur un site HTTPS, au vue de faire un tir de charges ensuite. Continuer la lecture de Enregistrer un scénario Jmeter d’un site en HTTPS via le proxy HTTP

Intégrer JMeter à Eclipse et Hudson pour faire des tests fonctionnels de webservices

Un petit billet pour voir envoyer vers un autre billet qui donne un tutoriel pour intégrer JMeter dans son Eclipse, puis configurer JMeter pour un test fonctionnel sur un webservice.

L’auteur ensuite nous montre l’automatisation via Ant, puis l’intégration du script automatisé dans Hudson.

JMeter in Eclipse and Hudson

Bonne lecture.

./