La version 2.6 est une version qui apporte de jolies améliorations tout en amenant son lot de corrections d’anomalies.

Voici quelques captures de quelques nouveautés importantes :

La plus ‘remarquable’ c’est l’ajout d’une barre d’outils sur la fenêtre principale de JMeter, qui permet d’avoir à portée de clic les principales actions de JMeter (dont le lancement d’un tir).

Ensuite, une amélioration qui me semble importante pour ceux qui utilisent JMeter pour tester des applications de type GWT RPC, SOAP/XML, etc. C’est l’ajout d’un onglet Données POST dans l’échantillon Requête HTTP. Celui-ci permet de visualiser et éditer bien plus facilement les données envoyées lors de l’exécution de la requête.

Dans le genre ‘quick and dirty’, c’est-à-dire lorsque vous devez faire un test de charge rapide pour un client (ou chef) qui vous le demande à la dernière minute genre à 17h30 un vendredi soir (si vous ce que je veux dire…;-)), voici le récepteur Graphique agrégé amélioré :

De nombreuses options de personnalisation du graphique généré ont été ajoutées, par exemple la possibilité de filtrer par le nom via une regexp les résultats à grapher, ou bien la possibilité de fixer l’échelle des ordonnées à une valeur permettant la comparaison aisée avec un graphique d’un premier tir.

Une petite boîte de dialogue qui peut sauver des heures de travail : la confirmation de la suppression. Si vous avez déjà utiliser JMeter, vous avez peut-être comme moi déjà eu « l’accident de suppression », sans le faire exprès vous avez supprimé un noeud de l’arbre important, genre un Groupe d’unités ou un Contrôleur Transaction avec plein de fils. Et là c’est la catastrophe ! vous n’avez pas sauvegarder votre script depuis un bon moment, et toutes votre variabilisation est perdue… En effet, JMeter n’a pas (encore) de fonctionnalité de retour en arrière (le fameux Ctrl-Z). Tout cela pour dire que cette petite boîte de dialogue va certainement être utile. NB. La fonctionnalité de retour arrière va peut-être être intégrée dans une future version de JMeter, un patch ayant été proposé et est en cours d’évaluation.

Une autre amélioration sympathique pour (par exemple) ceux qui utilisent beaucoup des scripts BeanShell (ou autres langages), c’est la console de visualisation du fichier journal de JMeter (le jmeter.log).

Cette console permettant donc de voir les messages informatifs et d’erreurs lors de l’exécution de JMeter. Utile donc pour la mise au point de script BeanShell ou pour surveiller le bon fonctionnement de JMeter.

La version 2.6 de JMeter a plein d’autres nouveautés, étant donné que la présentation de ces nouveautés a été aussi améliorée, je vous invite à suivre ce lien pour avoir encore plus de capture d’écran des nouveautés et aussi consulter la liste exhaustive des anomalies corrigées.

Dans tous les cas, la montée en version est recommandée.

Bon courage dans vos aventures JMeter !

Imaginez que vous devez faire un test de charge distribué avec un poste contrôleur et deux postes injecteurs. Malheureusement, vos injecteurs n’ont pas le même système d’exploitation que votre poste contrôleur. Ce dernier est sous Windows, et les injecteurs sont sous Linux.

Dans votre script JMeter, il y a un élément Source de données CSV qui vous permet (par exemple) d’avoir une liste d’identifiants/mot de passe de connexion.

Lors de la mise au point de votre script JMeter, vous utilisez seulement votre poste contrôleur, et la valeur du champ Nom de fichier dans votre Source de données CSV est :

c:/Temp/liste_login.csv

Ce chemin est valable sous Windows, mais bien entendu, ne sera pas valable sur vos injecteurs lorsque vous allez lancer le test distribué.

Juste avant ce test, il faut modifier le script JMeter pour changer la valeur du Nom de fichier par :

/tmp/liste_login.csv

Facile à faire, mais aussi facile à oublier de faire…

Voici un moyen de le faire automatiquement.

Ci-dessous un plan de test d’exemple :

Par rapport au commentaire de Vincent D. j’ajoute un élément Groupe d’unités de début. Ce dernier permet de réaliser l’opération de définition du chemin de fichier avant n’importe quel autre Groupe d’unités.

Donc, dans le Groupe d’unités de début, on place un Échantillon BeanShell qui va contenir un simple bout de code (Java) pour :

1. Récupérer le nom du système d’exploitation (depuis les Propriétés Java)
2. Faire un test sur le nom « windows », si oui on créé une propriété JMeter « CHEMIN » qui aura la valeur du chemin dans le poste Windows
3. Sinon, ce sera le chemin Linux / Unix et Mac

Le code :

String sOs = System.getProperty("os.name").toLowerCase();
 if (sOs.contains("windows")) {
 props.setProperty("CHEMIN", "c:/Temp/");
 } else {
 // couvre Linux/Unix/Mac
 props.setProperty("CHEMIN", "/tmp/");
 }

On notera que le chemin est déposé dans une propriété JMeter (et non une variable JMeter), car la propriété JMeter se propage à travers les Groupes d’unités, ce qui n’est pas le cas de la variable JMeter.

Ensuite, on peut donc utiliser notre propriété CHEMIN dans l’élément Source de données CSV pour avoir un chemin adapté en fonction du système d’exploitation.

On utilisera la fonction JMeter __P() pour récupérer la valeur de la propriété CHEMIN :

${__P(CHEMIN)}

Pour rappel, le SMTP (Simple Message Transfer Protocol) est le protocole normalisé d’échange de message électronique (email). Dans JMeter depuis la version 2.4, un nouvel échantillon appelé Requête SMTP a été ajouté pour avoir un client SMTP qui envoi donc un email.

Bien entendu, JMeter étant un outil de test de charge, avec cet échantillon, on peut faire un test de charge sur un serveur de messagerie franchement installé pour vérifier sa tenue de charge et robustesse (ce qui est mon cas), on peut aussi utiliser cet échantillon SMTP pour par exemple s’envoyer un email de rapport à la fin d’un test de charge « long » (qui dure plusieurs heures ou jours), ou tout simplement dans le cadre de la mise en place d’un système d’alerte en cas de temps de réponse dégradé d’un site web (par exemple) avec un script qui s’exécute toutes les x minutes ou heures.

Revenons à notre sujet, voici notre arbre JMeter tout simple pour ce test :

Et voici l’exemple d’échantillon SMTP configuré pour envoyer un message de test en utilisant les serveurs de Gmail :

NB : ici est présenté l’échantillon SMTP de la future version 2.4.1 (en date du billet)

Rien de méchant en soit, si vous utilisez votre compte Gmail en accès SMTP/POP ou SMTP/IMAP, la plupart de ces paramètres vous rappellerons quelque chose. Sinon, voici quelques commentaires, section par section.

Section Paramètres du serveur :

Juste au-dessus de la section, il y a bien entendu la traditionnelle section d’identification de l’échantillon et le champ Commentaires.

• Serveur : ici on indique le nom ou l’adresse IP du serveur SMTP
• Port : il existe plusieurs ports « officiels » pour le SMTP, le premier et plus ancien est le 25, sa version avec une couche SSL pour le chiffrement du transport sur le réseau est 465 (SMTPS), et une version permettant de chiffrement la partie authentification lors de l’établissement d’une session SMTP via StartTLS est le port 587. Chez GMail, on a la possibilité d’avoir ces trois ports ouverts.

Section Paramètres du courriel :

Ici c’est assez clair pour toute personne qui a déjà envoyée un email.

Section Paramètres d’authentification :

Lors d’un envoi d’un message via SMTP, il est possible au préalable de s’identifier. C’est souvent une mesure obligatoire demandée par les serveurs de messagerie pour lutter contre le SPAM et l’usurpation d’identité d’un email. Chez Gmail, c’est obligatoire.

Section Paramètres de sécurité :

Ici, on en revient aux Ports et options : SMTP : 25, SMTPS : 465 et StartTLS : 587

• Le port 25 n’utilise pas généralement de sécurité, donc on choisira « Pas de fonctionnalité de sécurité » si on a mis 25 dans le champ Port plus haut.
• Le port 465 utilise la couche SSL pour sécuriser le transport sur le réseau (chiffrement), donc on cochera « Utiliser SSL »
• Et le dernier port 587, c’est la négociation StartTLS de l’authentification, qui demandera donc de cocher « Utiliser StartTLS »
• Les autres paramètres concerne l’option « Utiliser SSL » et sont relatives aux modes d’utilisation et de confiance des certificats SSL. Pour un serveur SMTPS ayant un certificat SSL reconnu par une autorité de certification reconnue dans JAVA (donc déjà présent dans le fichier cacerts de l’environnement JAVA), il n’y a rien besoin de cocher. Par contre, si vous utilisez un certificat SSL auto-signé ou signé par une autorité de certification non reconnue, vous avez la possibilité de faire confiance à tous les certificats ou bien d’utiliser votre propre coffre de certificat local contenant la clé publique de votre autorité de certification ou certificat serveur (au lieu donc du cacerts).
• La petite option « Force le StartTLS » est pour donc force l’utilisation de la négociation StartTLS, souvent en conjugaison avec le port 25 (car on peut avoir du StartTLS sur le port 25).

Section Paramètres du message :

Ici c’est bien entendu le cœur de l’échantillon, avec le message à envoyer. Les champs Sujet, Message et Fichier attaché sont explicites de part leurs noms.

• L’option « Supprimer l’entête Sujet » permet d’envoyer un message sans sujet
• L’option « Ajouter un horodatage dans le sujet » permet d’avoir un timestamp correspondant au nombre de secondes depuis le 1er Janvier 1970 au moment de l’envoi du message
• L’option « Envoyer le message en texte » permet de revenir à un format de message SMTP dans sa version la plus simple (format RFC 822) au lieu d’un format MIME (multipart/mixed) qui lui est plus souple pour les messages avec accents et pièce jointe.
• Et l’option « Envoyer un message .eml » est pour envoyer un message au format EML (format d’export d’un message Outlook et utiliser dans beaucoup de client de messagerie).

Section Paramètres supplémentaires :

Deux dernières options :

• « Calculer la taille du message » qui fait ce que son nom indique, utile notamment dans le cas des messages avec pièces jointes et pour servir ensuite dans les statistiques de JMeter
• « Activer les traces de débogage ? » vous permettra de voir les échanges entre JMeter et le serveur SMTP sur la sortie standard (la console généralement)

Voilà, on en arrive à l’exécution de notre envoi.

Voici avec un récepteur Arbre de résultats, le résultat :

Ce sont les champs habituels de l’arbre de résultats, avec une mention pour le Message de retour, ici, indiquant : « Message successfully sent ! » signifiant la réussite de l’envoi.

On peut regarder sur l’onglet Données de réponses (et aussi Requête), on trouvera le corps du message email envoyé. Ci-dessous avec un message MIME (par défaut)

Et ici un message en texte pur (les balises MIME ont disparut).

Ceci clôture ce petit comment-faire pour envoyer un email avec JMeter. Bon courage.

La réponse à cette question est l’objet de ce tutoriel.

Les pré-requis :

• Un serveur Hudson (le mien est sous Linux Debian)
• Un script JMeter pour tester une application ou tout autre chose que sait tester JMeter (voir les différents tutoriels sur ce même blog)
• Changer le format de sortie des résultats de JMeter (au lieux de CSV, passer en JTL (xml)), pour cela, modifier dans le fichier jmeter.properties, la proprité suivante : jmeter.save.saveservice.output_format=xml
• L’installation du plugin « Hudson Performance plugin » depuis le gestionnaire des plugins intégré à Hudson, cf. la capture ci-dessous.

On va créer une nouvelle tâche dans Hudson (New Job).

On saisit un nom de tâche, puis on sélectionne l’option « Build a free-style software project » avant de clique sur le bouton OK.

Dans le formulaire de configuration de la tâche, dans la section Build on choisit l’invocation d’un script Ant.

Dans la configuration de l’invocation de Ant, on saisit la cible « all », et on ajoute dans les propriétés :

jmeter.dir=/var/lib/hudson/jobs/TestJMeter/jakarta-jmeter-2.4.1

Plus bas dans le formulaire de configuration de la tâche, on retrouve le plugin Performance. On le coche afin de l’activer.

Dans le champ Report files on saisit : « **/*.jtl » afin d’exécuter tous les fichiers .jtl (c’est-à-dire les fichiers script de test de JMeter) qui se trouveront dans l’espace de travail de la tâche (le workspace)

On pourra aussi configurer le champ Performance threshold afin de modifier le statut du « build » en fonction du pourcentage d’erreur trouvées.

Voilà, c’est fini pour le formulaire de configuration de la tâche, il faut bien entendu enregistrer le formulaire.

Maintenant, on entre dans une petite phase de « ligne de commande » afin de préparer son workspace.

On dépose sur le serveur Hudson, l’archive de JMeter (le tgz plutôt que le zip afin d’avoir les bons droits positionnés sur les fichiers).

Dans notre cas, l’archive jakarta-jmeter-2.4.1.tgz (nb. j’utilise une version de test de JMeter, la 2.4.1 n’est pas encore sortie à ce jour) est positionné dans /var/lib/hudson/jobs/TestJMeter

Ensuite on procède à la décompression de l’archive :

hudson@hudson:~/jobs/TestJMeter$ tar xfz jakarta-jmeter-2.4.1.tgz

On créé quelques répertoires :

hudson@hudson:~/jobs/TestJMeter$ mkdir workspace

hudson@hudson:~/jobs/TestJMeter$ mkdir workspace/scripts

On copie le fichier script JMeter dans le répertoire ci-dessous :

hudson@hudson:~/jobs/TestJMeter$ cp /tmp/test_webservices.jmx workspace/scripts

On édite le fichier de la tâche JMeter/Ant avec le contenu suivant :

hudson@hudson:~/jobs/TestJMeter$ vi workspace/build.xml

<project default="all">
 <!-- Define an environment variable pointing to JMETER folder or change this -->
 <property environment="env"/>
 <property name="jmeter-home" location="${jmeter.dir}"/>
 <!-- Should report include response data for failures? -->
 <property name="show-data" value="y"/>
 <!-- ant-jmeter.jar comes with jmeter, be sure this is the release you have -->
 <path id="ant.jmeter.classpath">
     <fileset dir="${jmeter-home}/extras">
         <include name="ant-jmeter*.jar"/>
     </fileset>
 </path>
 <taskdef
     name="jmeter"
     classname="org.programmerplanet.ant.taskdefs.jmeter.JMeterTask"
     classpathref="ant.jmeter.classpath" />
 <target name="clean">
     <delete dir="results"/>
     <delete file="jmeter.log"/>
     <mkdir dir="results/jtl"/>
     <mkdir dir="results/html"/>
 </target>
 <target name="test" depends="clean">
     <jmeter
          jmeterhome="${jmeter-home}"
          resultlogdir="results/jtl">
          <testplans dir="scripts" includes="*.jmx"/>
     </jmeter>
 </target>

 <property name="lib.dir" value="${jmeter-home}/lib"/>
 <!-- Use xalan copy from JMeter lib directory to ensure consistent processing with Java 1.4+ -->
 <path id="xslt.classpath">
     <fileset dir="${lib.dir}" includes="xalan*.jar"/>
     <fileset dir="${lib.dir}" includes="serializer*.jar"/>
 </path> 

 <!-- This is not needed for the plugin, but it produces a nice html report
 which can be saved usin hudson's archive artifact feature -->
 <target name="report" depends="test">
     <xslt
         classpathref="xslt.classpath"
         basedir="results/jtl"
         destdir="results/html"
         includes="*.jtl"
         style="${jmeter-home}/extras/jmeter-results-detail-report_21.xsl">
         <param name="showData" expression="${show-data}"/>
     </xslt>
     <!-- add images for best report display -->
     <copy file="${jmeter-home}/extras/expand.jpg" tofile="results/html/expand.jpg"/>
     <copy file="${jmeter-home}/extras/collapse.jpg" tofile="results/html/collapse.jpg"/>
 </target>
 <target name="all" depends="test, report"/>
</project>

Une fois que le fichier build.xml est enregistré, revenir sur l’interface de gestion de Hudson. Au niveau de son projet, choisir le lien « Build Now » afin de lancer le premier test.

Hudson va donc lancer le test JMeter et afficher son succès ou échec. Depuis la console de gestion Hudson, au niveau de la tâche, il est possible d’avoir la sortie de console. La capture d’écran montre un exemple d’exécution réussie.

Sur la page d’accueil du projet dans Husdon, après quelques exécutions de « build », de nouveau graphiques apparaissent. Le lien Performance Trend permet d’avoir le détail des indicateurs de performances.

La capture ci-dessous montre les graphiques des indicateurs de performance.

Il est également possible de consulter le rapport HTML produit par la tâche JMeter/Ant. Pour cela, on se place sur la section Workspace, puis results > html et on clique sur le fichier HTML.

La capture d’écran ci-dessous montre le rapport HTML produit par la tâche JMeter/Ant.

Et voilà pour ce petit tutoriel de « mise en liaison » de JMeter et Hudson.

Bien entendu, en disposant des tâches hudson habituelles de construction d’une release de son application (récupération SVN, compilation, ear/war et déploiement sur un serveur de test) avant l’exécution du test JMeter et la génération du rapport, on a un cycle de release avec test de charge.

./

Avant de vous montrer comment le trouver et l’utiliser, parlons-en un peu.

Comme vous le savez peut-être, JMeter dispose d’un élément Extracteur Expression régulière dans la catégorie Post-processeurs. La vocation de cet élément Extracteur Expression régulière est d’extraire à partir d’une expression régulière une ou plusieurs chaînes de caractères depuis la réponse reçue d’un échantillon de test. La puissance en termes d’extraction de données de cet élément est très forte, cependant, il est parfois peu aisée de trouver du premier coup la bonne expression régulière qui fera ce que vous voulez. En effet, vous devez jouer et rejouer le scénario pour tester votre expression régulière tant qu’elle n’est pas au point.

C’est là qu’intervient le Testeur de RegExp.

Vous l’avez déjà compris avec son nom, cet élément est un testeur d’expression régulière « au format JMeter ». Ce testeur ne se branche pas sur un échantillon, mais est un type de visualiseur du récepteur Arbre de résultats, ce qui signifie que vous allez pouvoir effectuer des tests d’expression régulière directement sur les résultats d’échantillons se trouvant dans un Arbre de résultats.

Par exemple, si vous avez suivi ce petit billet sur l’enregistrement de votre scénario fonctionnel pour une réutilisation à froid, ou bien que vous avez exécuté une fois votre scénario de test et qu’il y a un problème sur une expression régulière, le tout avec un Arbre de résultats, vous pourrez utiliser le Testeur d’expression régulière (de RegExp) pour créer ou valider votre expression régulière.

La capture d’écran ci-dessous montre le menu permettant d’accéder au testeur depuis un Arbre de résultats.

Ensuite dans le champ Expression régulière, il suffit de saisir son expression régulière (en suivant le format de JMeter, à savoir Jakarta ORO).

Dans l’exemple ci-dessous, l’expression régulière est « debian(.+?).html », signifiant : tout ce qui commence par debian et se termine par .html avec au milieu n’importe quoi. Les parenthèses indiquant que l’on souhaite récupérer ce « n’importe quoi » (dans une variable JMeter dans le cas d’un Extracteur RegExp)

Dans le champ texte de la réponse du Testeur de RegExp, on trouve les éléments de réponses suivants :

Match count: 6
Match[1][0]=debian-squeeze-772.html
Match[1][1]=-squeeze-772.
Match[2][0]=debian-squeeze-772.html
Match[2][1]=-squeeze-772.
Match[3][0]=debian-squeeze-6-0-762.html
Match[3][1]=-squeeze-6-0-762.
Match[4][0]=debian.org/releases/testing/index.fr.html
Match[4][1]=.org/releases/testing/index.fr.
Match[5][0]=debian-squeeze-6-0-762.html
Match[5][1]=-squeeze-6-0-762.
Match[6][0]=debian-squeeze-6-0-762.html
Match[6][1]=-squeeze-6-0-762.

La première ligne signifie qu’il y a eu 6 correspondances trouvées pour l’expression régulière.

Ensuite, on a des groupements « matrice », les correspondances sont indiquées sur deux lignes (ou plus, c’est en fonction du nombre de parenthèses indiquant les sections à récupérer). Pour les lignes 2 et 3 :

• la première donne la chaîne complète de correspondance de l’expression régulière
• la deuxième donnant la valeur voulant être récupérée (le n’importe quoi des parenthèses)

Les lignes suivantes indiquant les autres correspondances en suivant le même modèle.

Si l’élément Testeur de RegExp ne vous donne pas de réponse (écran blanc), c’est qu’il y a un problème dans le format de votre expression régulière.

Si vous êtes satisfait de votre expression régulière, il ne vous reste plus qu’à la copier/coller dans un élément Extracteur Expression régulière.

Pour plus d’aide sur les expressions régulières, j’ai fait les quelques billets suivants :

• Quelques cas d’utilisation de l’extracteur d’expression régulière dans JMeter
• Trouver le bon élément dans une liste avec les expressions régulières et en mode ligne unique

Je profite de ce billet, pour remercier Jean-Louis et Jean-Luc, deux métrologues, qui m’ont suggéré l’idée d’ajouter ce tester d’expression régulière dans JMeter. Et Jean-Louis, de nouveau, pour m’avoir fourni un exemple de code Java avec le moteur d’expression régulière du JDK.

./

1. Identifier le scénario fonctionnel qui sera rejoué par les utilisateurs virtuels
2. Enregistrer ce scénario dans JMeter au travers d’un session de navigation avec votre navigateur
3. Affiner le scénario (variabiliser ce qui doit l’être, ajouter des assertions réponses, etc.)
4. Lancer votre tir

Le problème, c’est que vous avez accès à l’application cible pendant une période limitée, genre 15 min, ou bien que vous n’avez pas accès directement à l’application, vous devez passer un poste de travail pour accéder à l’application, ce poste étant bien entendu moins bien que votre ordinateur (genre c’est pas Linux )

Que diriez-vous d’enregistrer votre session de navigation complète, c’est-à-dire les requêtes avec leurs paramètres mais surtout les réponses reçues par le navigateur, afin de pouvoir affiner votre scénario « à froid », sans connexion avec l’application cible, ou carrément tranquillement à la maison ?

Voici le mode d’emploi. Partie 1 : l’enregistrement dans un fichier.

Voici, ci-dessous, un arbre d’exemple pour l’enregistrement d’une session de navigation dans un JMeter (version 2.4).

L’élément Serveur Proxy HTTP va capturer les requêtes HTTP effectuées par votre navigateur (ce dernier étant configuré pour utiliser JMeter comme proxy). Puis JMeter va créer les requêtes HTTP correspondantes dans le Contrôleur Enregistreur.

Vous remarquerez la petite particularité de mon élément Serveur Proxy HTTP : il a un récepteur Arbre de résultats en tant que fils.

Cet Arbre de résultats permet de :

• De voir le détail des requêtes HTTP capturées par le proxy JMeter
• D’enregistrer la session de navigation au format JMeter (extension .JTL) afin de pouvoir revenir sur la session « à froid » (sans connexion au serveur).

Pour indiquer à JMeter que vous voulez enregistrer les données (requêtes/réponses) captées par le proxy, il faut donc un élément de type récepteur (comme mon arbre de résultats), puis dans le champ Nom du fichier il faut saisir (avec ses petits doigts, sans utiliser le bouton Parcourir situé à droite) le chemin complet du fichier destination. L’extension usuelle de JMeter pour ce type de fichier est .jtl.

Ensuite il faut cliquer sur le bouton Configurer qui se trouve à droite du nom du fichier. La fenêtre ci-dessous apparaît :



Ici, on coche toutes les cases à cocher (histoire de ne pas se casser la tête), puis on ferme la fenêtre.

Ensuite, il faut revenir dans l’élément Serveur proxy HTTP afin de le (re)démarrer pour qu’il puisse commencer à enregistrer les données lors de la navigation avec votre navigateur.

Voilà, maintenant vous avez un fichier JTL qui contient tout ce qu’il vous faut pour travailler tranquillement, et à froid, à l’affinage de votre script JMeter.

(Ou, autre utilisation possible : zipper le fichier jtl et l’envoyer à quelqu’un d’autre pour assistance dans votre travail.)

Partie 2 : Revoir son fichier JTL

Vous êtes maintenant prêt pour travailler sur l’affinage du script, il faut donc ouvrir son fichier JTL dans JMeter.

Ci-dessous, un JMeter fraîchement lancé (mais vous pouvez aussi le faire depuis un JMeter ayant déjà son arbre) :

On se place sur le Plan de test, puis avec le bouton droit de la souris : Ajouter > Récepteurs > Arbre de résultats.

Ceci ajoute un nouvel élément Arbre de résultats, dans lequel on va cliquer sur le bouton Parcourir… qui est situé dans la partie à droite sur l’écran (pas dans les menus).

Dans la nouvelle fenêtre qui s’affiche, on recherche son fichier JTL, et on clique sur Ouvrir.

Et hop, l’arbre de résultats se remplit les données enregistrées (requêtes et surtout les réponses) :

Y-a-pu-qu’à faire l’affinage ou toute autre chose que vous aimeriez.

./

Un des pré-requis est d’avoir un serveur ActiveMQ démarré. Pour cela (et pour faire simple), il suffit de télécharger les fichiers binaires depuis le site Apache ActiveMQ, de décompresser l’archive, d’aller dans le répertoire de décompression et exécuter la commande suivante :

./bin/activemq start

Ensuite, vous pouvez vérifier que cela fonctionne en visitant l’interface d’administration à l’adresse suivante http://localhost:8161/admin/

On reviens à JMeter maintenant et notre petit tutoriel sur l’utilisation de JMeter pour tester ActiveMQ.

Une étape préalable est de récupérer les fichiers JAR d’ActiveMQ afin de permettre à JMeter de « parler JMS » avec votre serveur ActiveMQ. Le mieux est de prendre l’archive activemq-all-X.X.X.jar (X.X.X en fonction de la version) à partir du répertoire ActiveMQ décompressé, puis de placer le fichier JAR dans le répertoire JMETER_HOME/lib. L’aide officielle pour cette étape est ici.

Voici maintenant notre plan de test tout simple pour illustrer un test JMS sur une file « point à point ».

On aura dans ce plan de test, un groupe d’unités, appelé GU Point-à-Point, avec seulement un utilisateur, qui monte en charge en une seconde et qui fera trois itérations.

Ensuite, on en vient à la Requête JMS Point-à-point qui va faire tout le travail. C’est-à-dire, qu’elle va déposer un message sur une file de requête (Q.REQ) et lire sur une file de réception le message qu’elle a déposé (Q.RPL).

Voici quelques commentaires ou explications sur les champs de cet élément JMS Point-à-point :

Il ne reste plus qu’à lancer le micro-test :

L’arbre de résultats nous montre une exécution réussie

Et là, la capture d’écran du contenu de message.

Pour revenir à ActiveMQ et sa console, à partir de celle-ci on peut voir (surveiller) les messages déposés/lues dans les files.

On peut également voir les connexions ouvertes par JMeter pendant le tir. Au total 2 connexions (une pour le dépôt et une pour la lecture).

Quelques commentaires :

• En interne, JMeter démarre le JMS Listener (le processus d’écoute) sur la file de réception avant même le début du test (au moment de la compilation de l’arbre du script JMeter). Ce qui signifie que le nom de la file ne supporte pas les variables JMeter non définies au moment du lancement du test (donc une variable récupérée via un extracteur d’expression régulière ne fonctionne pas, ou bien des noms de files JMS qui sont récupérées via une Source de données CSV).
• L’aide officielle de JMeter sur les tests JMS est ici (JMS Point-to-Point) et là (Building a JMS Point-to-Point Test Plan).
• Un lien vers un tutoriel IBM pour utiliser JMeter avec WebSphere MQ

./

Commençons par le plan de test : très simple, une requête avec en élément fils un extracteur d’expression régulière.

La requête HTTP est simplement la page d’accueil de ce blog.

On place un échantillon Débogage après la requête HTTP qui possède l’extracteur d’expression régulière, il permet d’afficher différentes informations internes à JMeter. Ici, on s’intéresse aux valeurs des variables de JMeter.

Ensuite (enfin) vient l’extracteur d’expression régulière, on commence par un « simple ».

Quelques explications :

• Champs réponse à cocher : Corps. La portée de l’extracteur regexp sera le corps de la réponse (le texte html en général)
• Nom de référence : le nom de la variable dans laquelle JMeter va déposer les données récupérée par l’expression régulière
• Expression régulière : ici « (milamber) », qui signifie : « je recherche le mot milamber, et je voudrais récupérer la valeur ». Il n’y a pas à proprement parler d’expression régulière ici, car aucun caractères de correspondance de caractères n’est utilisé (par exemple « * »).
• Canevas : $1$ correspondant au premier « couple » de parenthèses dans l’expression régulière. Donc ici « milamber »
• Correspond au num. : 0. Parmi « tous les milamber » qui vont être trouvés, JMeter en choisi un au hasard et le place dans la variable JMeter NOM_VARIABLE
• Valeur par défaut : correspond à la valeur que va prendre la variable NOM_VARIABLE si jamais l’expression régulière n’est pas trouvée (autrement si il n’y a pas de milamber dans le corps de la réponse)

On exécute (on lance) le test JMeter. Avec le récepteur Arbre de résultats, on peut déjà voir les données de réponse de la page d’accueil de ce site. On voit qu’il y a plusieurs occurrences de « milamber ».

Dans l’échantillon Débogage, dans l’onglet Données de réponse, on retrouve la variable NOM_VARIABLE.

Quelques explications sur les différents « NOM_VARIABLExxx » que l’on trouve.

• NOM_VARIABLE=milamber, correspond bien entendu à la valeur recherchée (et donc trouvée par JMeter) à partir de l’expression régulière
• NOM_VARIABLE_g=1, c’est le nombre de variables $x$ trouvées
• NOM_VARIABLE_g0=milamber, c’est la chaine correspondant à l’expression régulière entière
• NOM_VARIABLE_g1=milamber, correspond à ce qu’a trouvée l’expression régulière dans la partie entre parenthèses

Ici, la variable NOM_VARIABLE_g0 est la même que NOM_VARIABLE_g1 car l’expression régulière est (milamber), et est très simple. Dans le dernier exemple de ce billet, ce n’est pas le cas, voir plus bas.

Changeons l’expression régulière en mettant simplement un M majuscule à Milamber :

Le résultat dans l’échantillon Débogage, c’est « Milamber » en majuscule. Donc l’extracteur d’expression régulière est sensible à la casse.

Changeons l’expression régulière par (Milember), donc volontairement avec une faute.

Ici, comme il n’y a pas de mot Milember dans les données de réponse de la page HTML retournée, la valeur de NOM_VARIABLE est la valeur par défaut (ici le message d’erreur).

Revenons à (milamber) comme expression régulière. Comme je sais qu’il y a plusieurs « milamber » dans la page HTML, et que j’aimerais bien tous les retrouver, on change la valeur du champ Correspond au num par « -1 ». Cette valeur va indiquer à JMeter d’aller chercher toutes les occurrences de l’expression régulière.

Dans la vue données de réponses de l’échantillon Débogage, on a maintenant une suite de NOM_VARIABLE_x où x correspond au numéro de « milamber » trouvé. La variable NOM_VARIABLE se retrouve avec la valeur par défaut.

Quand on regarde à la fin des variables affichées par l’echantillon Débogage, on trouve une variable spéciale NOM_VARIABLE_matchNr = 195. Ce dernier correspond au nombre de « milamber » trouvé.

On a vu que l’extracteur d’expression régulière était sensible à la casse. Pour le rendre « insensible », il suffit de faire précéder l’expression régulière par « (?i) ».

Dans la liste des variables trouvées, on a maintenant à la fois des « milamber » et des « Milamber ».

La dernière expression régulière va indiquer que l’on recherche exclusivement les « milamber » suivi de quelque chose et suivi de « .net ». C’est à dire les milamber dans « milamberspace.net ».

Le « quelque chose » est symbolisé par « .+ »

Le suivi de « .net » est symbolisé par « ?\.net » où la barre oblique inversée (l’anti-slash) sert à désactiver la propriété particulière du point dans une expression régulière.

Dans les résultats, on a donc que les « milamber » dans la chaîne « milamberspace.net ».

Voici pour ce billet montrant quelques cas d’utilisation de l’extracteur d’expression régulière. Bien entendu, ce dernier n’est pas limité à ces cas, il ne tient qu’à vous de faire de belles expressions régulières pour extraire des chaînes à partir des réponses à vos requêtes.

Bonnes regexps !

Deux liens :

• La page du manuel JMeter sur l’extracteur d’expression régulière
• La page du manuel JMeter sur les expressions régulières

./

En effet, vous pouvez avoir l’idée ou l’envie de faire une série de test en jouant sur certains paramètres de votre scénario JMeter, le tout en ligne de commande. Par exemple, faire un test avec 1 utilisateur, puis le même test avec 10 utilisateurs, et le même avec 100 utilisateurs.

Bien évidemment vous pouvez les lancer depuis l’interface graphique de JMeter, à la suite, tout en modifiant le paramètre du nombre d’utilisateurs dans l’interface, mais c’est trop facile .

Donc pour le faire en ligne de commande, il faut d’abord passer par l’interface graphique JMeter. En effet, nous avons besoin d’utiliser une fonction JMeter qui va permettre de lire une propriété JMeter et renvoyer sa valeur. Cette fonction doit être appelée à la place de la valeur du champ correspondant au paramètre que l’on veut rendre « paramétrable »…

Le mieux est d’abord de voir la capture d’écran :

Les différents ${__P(xxx,yyy)} correspondent à notre fonction JMeter qui permet de lire une propriété JMeter, et qui la renvoie.

Donc ici, on vient d’utiliser la fonction __P() (avec deux caractères soulignés avant le P) pour définir trois paramètres :

• Le nombre d’unités d’exécution, qui prend soit la valeur de la variable JMeter nombreUnites ou si elle est inexistante, la valeur par défaut « 10 »
• La durée de montée en charge, qui prend soit la valeur de la variable JMeter dureeMontee ou si elle est inexistante, la valeur par défaut « 50 »
• La nombre d’itérations, qui prend soit la valeur de la variable JMeter nombreIterations ou si elle est inexistante, la valeur par défaut « 100 »

Comme vous l’aurez compris, la fonction __P() a deux paramètres, le premier pour indiquer la clé de la propriété à rechercher, lire et renvoyer, et le second (optionnel) étant la valeur par défaut si la clé n’existe pas.

Une fois que vous avez défini ainsi les différents champs que vous souhaitez « paramètriser », il ne reste plus qu’a lancer JMeter en ligne de commande avec la ou les valeurs.

Pour cela, on utilise l’option « -J » de JMeter. Celle-ci permet de définir un couple clé/valeur correspondant à une propriété JMeter. Pour notre exemple, la ligne de commande sera donc :

jmeter -n -l resultats.csv -t scenario.jmx -JnombreUnites=5 -JdureeMontee=10 -JnombreIterations=100

(Petit rappel : -n : mode non-gui, -l : fichier de résultats, -t : fichier scripts JMeter)

Voilà, maintenant vous pouvez jouer sur les valeurs de ces paramètres afin de faire plusieurs types de tests.

Plus d’infos sur les fonctions, voici la page réservée aux fonctions du manuel JMeter

./

Ce tutoriel a pour objectifs :

1. Rappeler l’utilisation de Requête JDBC pour accéder à une base de données, et récupérer dans un ensemble de variables les résultats de requête JDBC
2. Montrer comment effectuer l’ajout d’une fiche Utilisateur dans un serveur LDAP via une Requête LDAP étendue de JMeter
3. Montrer le fonctionnement du Contrôleur Pour chaque dans JMeter
4. Montrer un petit exemple de Pré-Processeur BeanShell

Voici le plan de de test final.

On observe deux sections :

1. Base de données : qui est un Contrôleur Simple regroupant les éléments nécessaires à la partie JDBC afin d’accéder à la base et faire la requête SQL qui va permettre de récupérer les utilisateurs à créer.
2. LDAP : qui est aussi un Contrôleur Simple regroupant les éléments permettant la connexion au serveur LDAP et effectuer la requête d’ajout dans le LDAP des utilisateurs.

Concernant la partie Base de données, je vous revois vers ce billet pour avoir plus de détails sur sa mise en place. Ci-dessous, je vais seulement commenter certains éléments de cette partie.

L’élément Requête JDBC correspond à la requête SQL que JMeter va effectuer pour obtenir une liste de noms et de prénoms qui seront utilisés dans la section LDAP.

• Le champ Nom de liaison fait référence au ‘pool’ JDBC configuré dans l’élément Configuration de connexion JDBC
• Le type de requête est Select Statement, on fait donc une requête SQL commençant par SELECT :
  • SELECT ID, NOM, PRENOM from BOXERS
• Dans le champ Noms des variables, on donne les variables (JMeter) qui vont recevoir les données. Pour nous, cela sera VAR_ID, VAR_NOM, VAR_PRENOM.

A l’exécution, la requête SQL retournera une liste de noms et les placera dans les variables correspondantes, avec un suffixe _X où X est le numéro de la ligne retournée.

Pour la section suivante, LDAP, on utilisera donc ces variables pour faire l’ajout dans le LDAP.

Ainsi voici la partie LDAP : le premier élément est une Requête LDAP étendue qui va permettre de faire la connexion avec le serveur LDAP.

Pour cela, on choisi le type de test « Unité liée », et on complète les différents champs nécessaires :

• Nom du serveur (ou adresse IP)
• Port : 389 (correspondant au port par défaut pour le protocole ldap)
• DN : nom du suffixe de l’annuaire
• Identifiant : un compte disposant des droits pour modifier l’annuaire (ici c’est l’administrateur LDAP)
• Mot de passe associé au compte ci-dessus
• Délai d’attente de connexion : paramètre optionnel qui permet de faire échouer l’échantillon (de connexion) si jamais la connexion n’est pas ouverte
• La case à cocher permet de faire une connexion via le protocole LDAPS (via SSL donc) (accompagné par le port 636 en général)

Ensuite, on en profite pour faire l’opération inverse de la connexion : la Déconnexion. Pour cela, on choisit tout simplement le type de test « Délier les unités ». Cette requête sera placée en fin du scénario.

Passons aux éléments qui vont nous permettre d’ajouter les fiches annuaires dans le LDAP.

Le contrôleur ci-dessus, Pour chaque va tout simplement (efficacement je dirais), parcourir une à une les variables VAR_NOM_x où x est le numéro de ligne des résultats de la requête SQL précédente. À chaque itération, il va affecter à la variable NOM la valeur de VAR_NOM_x. (on notera la correspondance entre VAR_NOM de la requête JDBC Select et le VAR_NOM_x du contrôleur)

Ici, on ajoute un Compteur JMeter qui nous permet de connaître (suivre) le numéro de ligne, afin que nous puissions l’utiliser dans la prochaine requête pour générer des variables.

Nous voilà dans la requête « costaude », il s’agit d’une Requête LDAP étendue qui va traiter l’ajout. Ainsi, on choisit le type de test « Add test ».

Puis le champ Entry DN nous permet d’indiquer l’identifiant unique de la fiche dans l’annuaire.

Le tableau suivant, permet d’ajouter les couples « clé: valeur » suivant le principe du fichier LDIF (importation de comptes LDAP).

On notera les points suivants :

• ${__V(VAR_PRENOM_${CPT})} permet de générer la variable « ${VAR_PRENOM_x} pour chaque itération du Contrôleur Pour chaque
• ${NEW_NOM} et ${NEW_PRENOM} sont des variables définies dans un Pré-processeur BeanShell (ci-dessous)

Dans la requête d’ajout, il est important de ne pas oublier les éléments « objectclass » qui vont définir la structure de la fiche annuaire.

En fils de la requête d’ajout, on place donc un Pré-processeur BeanShell, qui va permettre d’effectuer quelques actions (ou préparations) sur les données avant leur utilisation.

Tout d’abord, on récupère la variable CPT (via vars.get( »GET »)), puis avec une concaténation, on récupére la valeur de la variable VAR_PRENOM_x. On supprime les points et enlève les guillemets (car certains noms dans la base des boxers ont des pseudonymes entre guillemets). Puis on refait la même chose avec le NOM.

Pour finir, on génère l’adresse email via un petit passage en minuscule et une concaténation du domaine de messagerie.

A chaque fois, on utilise le vars.put pour déposer des nouvelles variables dans JMeter.

Ensuite, avec l’élément suivant, une Assertion Réponse, j’anticipe sur l’exécution et la vérification que tout s’est bien passé. En effet, si l’exécution de la requête d’ajout LDAP fonctionne correctement, le résultat contient « <responsemessage>Success</responsemessage> ». L’assertion sur ce texte va nous permettre de détecter rapidement les cas en erreur (si il y en a).

Après la requête d’ajout, on place une requête de recherche dans le LDAP (type de test : Search test). C’est optionnel, c’est juste pour faire une seconde vérification du bon ajout.

On notera :

• Le champ Search Filter qui est ici le « uid » inséré
• Le champ Scope est positionné à Effectuer une recherche ‘onelevel’ (on ne recherche pas dans les sous-éléments de l’arbre LDAP)
• Le champ Size limit pour limiter à 1 le résultat retourné (on fait une recherche unitaire)
• Le champ Limite de temps à 10000 (ms) pour faire échouer l’échantillon si le serveur LDAP est trop long à répondre
• Le champ Attributes (optionnel) qui permet de choisir les champs à récupérer, ici le CN, SN et Mail
• Et pour finir, la case à cocher Examiner les résultats de recherche ? va permettre d’avoir dans les résultats du test, les valeurs des champs récupérés afin notamment de faire (par exemple) une assertion.

Ensuite (enfin) on peut passer à l’exécution du scénario JMeter.

Pour cela, on grade la configuration par défaut du Groupes d’unités, à savoir : 1 unité qui monte en charge en 1 seconde et qui faire 1 itération (1-1-1).

(c’est le Contrôleur Pour chaque qui se charge des itérations sur les utilisateurs)

Voici l’arbre de résultats :

Si tout s’est bien passé, tout est vert. Dans les données de réponses, on voit les résultats des requêtes LDAP, avec la valeur Success.

On peut également vérifier dans les données de réponses que par exemple la génération des adresses email s’est bien déroulée.

Un récepteur Résultats d’assertion, configuré pour afficher uniquement les erreurs, permet de voir les utilisateurs qui ont eu un problème lors de l’exécution. Ici, il y a eu des soucis visiblement sur les noms de boxers qui ont un caractère accentué…

Et voilà, avec ce tutoriel, on découvre que JMeter sait faire d’autre chose qu’un test de charge Web.

Vous noterez que ce type de scénario, fait de JMeter une sorte d’ETL (Extract-Transform-Load). Ainsi, on peut même imaginer d’adapter ce scénario pour maintenir une synchronisation entre une base de données et un LDAP, le tout en exécutant JMeter en mode non-gui dans une tâche programmée ou un cron.

Je prépare une suite à ce tutoriel concernant la conversion automatisée des mots de passe stockés ici en clair dans le LDAP, vers des mots de passe stockés en SHA-1.

Bons scénarios.

En annexes :
A/ Un petit SELECT de ma base de données (histoire de montrer sa structure)

mysql> select * from BOXERS limit 10;
 +----+----------+------------+
 | ID | PRENOM   | NOM        |
 +----+----------+------------+
 |  1 | Muhammad | Ali        |
 |  2 | Lou      | Ambers     |
 |  3 | Vito     | Antuofermo |
 |  4 | Jorge    | Arce       |
 |  5 | Alexis   | Arguello   |
 |  6 | Henry    | Armstrong  |
 |  7 | Abe      | Attell     |
 |  8 | Monte    | Attell     |
 |  9 | Yuri     | Arbachakov |
 | 10 | Satoshi  | Aragaki    |
 +----+----------+------------+
 10 rows in set (0.03 sec)

B/ Le format LDIF d’exemple (qui permet de connaître les champs à ajouter dans la requête LDAP d’ajout, mais entendu, il faut l’adapter pour que cela colle avec le vôtre (serveur LDAP))

dn: uid=milamber,ou=Users,dc=milamberspace,dc=net
objectclass: organizationalPerson
objectclass: person
objectclass: top
objectclass: inetOrgPerson
uid: milamber
userPassword: jmeter2009
cn: milamber
mail: milamber@milamberspace.net
displayname: Milamber
givenname: Milamber
sn: Milamber

./