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.

• Créer des plans de tests de charge réalistes
• Développer un plan de test avec JMeter

Par le passé, il avait déjà publié un autre tutoriel sur l’audit de performances d’une application en Java EE.

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.

./

Comme pour le premier test, nous continuons avec la messagerie orientée message (MOM) Apache ActiveMQ.

Après avoir téléchargé l’archive binaire d’ActiveMQ, on le décompresse, puis on le démarre avec ces commandes :

cd <Repertoire_ActiveMQ>
./bin/activemq start

Il est possible de vérifier que le serveur ActiveMQ fonctionne bien en se connectant sur http://localhost:8161/admin/ correspondant à l’URL de l’interface d’administration.

Du coté de JMeter voici comment ce présente notre petit test :

Tout d’abord, on notera la présence de 2 Groupes d’unités : un réservé pour l’Abonnement et un autre pour la Publication. En effet, avec ces deux Groupes d’unités on va demander à JMeter de gérer « deux utilisateurs virtuels » indépendamment, l’un chargé de publier des messages, l’autre chargé de profiter de son abonnement à la file de messages c’est-à-dire la réception des messages publiés par l’autre utilisateur.

Regardons en détail :

Tout d’abord, on a le Groupe d’unités réservé à l’Abonnement, c’est-à-dire la récupération des messages publiés par le publieur. Ici on fait simple : 1 utilisateur virtuel qui fait 4 itérations.

Ensuite vient la requête JMS Abonnement avec les paramètres suivants :

• Fabrique de connexion initiale : org.apache.activemq.jndi.ActiveMQInitialContextFactory
• URL du fournisseur : tcp://localhost:61616 (les valeurs par défaut de ActiveMQ)
• Fabrique de connexion : ConnectionFactory
• Destination : dynamicTopics/MyStaticTopic1 (ici on utilise une fonctionnalité d’ActiveMQ avoir des Topics (sujets) qui sont créés dynamiquement dès qu’il est sollicité) (sinon il faut créer le topic via l’interface d’administration d’ActiveMQ)
• Evaluer : Au démarrage. Ici c’est une nouvelle fonctionnalité ajoutée après la version 2.4. C’est en effet une version de développement que j’utilise ici. Par défaut dans les versions < 2.4 le nom de la Destination est « static », il est lu au démarrage du test (avant même le lancement des unités d’exécution) et reste figé durant tout le tir, ce qui a pour conséquence d’interdire une valeur contenant une variable JMeter). L’option « Au démarrage » correspond à cette fonctionnalité. L’option « A chaque échantillon » demande à JMeter de procéder à l’évaluation de la valeur de la Destination juste avant l’exécution de la requête. Cette option permet d’avoir des variables JMeter dans le champ Destination.
• Nombre d’échantillons à agréger : 1 (on récupère 1 seul message par exécution)
• Délai : 10000 ms correspondant au temps d’attente maximum que la requête JMS Abonnement va patienter pour recevoir un message avant de se mettre en échec de récupération.

Maintenant on passe au Groupe d’unités réservé à la Publication.

Même traitement : 1 utilisateur virtuel qui fait 4 itérations. (On garde ainsi une cohérence avec le groupe d’unités Abonnement.)

Ici on a l’élément Action test qui va faire faire une pause de 2 secondes à l’unité. Pourquoi ? Parce qu’il faut (pour ce scénario) être certain que le topic (sujet) possède bien des requêtes d’Abonnement en écoute avant la publication d’un message. On laisse ainsi le temps au Groupe d’unités Abonnement d’avoir sa requête en écoute de la file.

On regarde maintenant les paramètres de la requête de Publication JMS :

• Fabrique de connexion initiale : org.apache.activemq.jndi.ActiveMQInitialContextFactory
• URL du fournisseur : tcp://localhost:61616 (les valeurs par défaut de ActiveMQ)
• Fabrique de connexion : ConnectionFactory
• Destination : dynamicTopics/MyStaticTopic1 (ici on utilise un fonctionnalité d’ActiveMQ avoir des Topics (sujets) qui sont créés dynamiquement dès qu’il est sollicité) (sinon il faut créer le topic via l’interface d’administration d’ActiveMQ)
• Evaluer : Au démarrage. (voir l’explication ci-dessus dans les paramètres de la requête JMS d’Abonnement)
• Nombre d’échantillons à agréger : 1 (on envoi 1 seul message par exécution)
• Message texte: un simple message avec une fonction JMeter (time) pour avoir un timestamp.

Voilà, il reste maintenant à tester l’exécution du scénario. Le serveur ActiveMQ est bien démarré, on lance le script (un petit CTRL-R).

Dans le récepteur Arbre de résultats, on peut observer les résultats. On peut y voir une alternance entre la Publication et l’Abonnement. (après chaque publication, le message publié est reçu par l’échantillon Abonnement).

Avec l’onglet Requête du récepteur Arbre de résultats, on peut avoir les détails de la requête JMS, en particulier le JMSMessageId qui permet de faire (si besoin) un rapprochement entre l’émission et la réception des messages JMS.

Pour finir, on regarde un élément JMS Abonnement, qui lui, indique qu’un message a été correctement reçu et affiche les détails de la requête JMS, avec son JMSMessageId.

On notera que : la requête JMS Abonnement arrive après la publication (ce qui est normal) dans l’arbre de résultats, bien que la date de début d’échantillon (onglet Résultat de l’échantillon) est 2 secondes plus tôt que la requête JMS Publication précédente. Du coup le temps de réponse est de 2022 ms, car 1/ les deux Groupes d’unités démarrent en même temps, 2/ mais celui de la Publication a un élément Action test effectuant une pause de 2 secondes, 3/ donc l’élément JMS Abonnement attends 2 secondes que l’élément Publication envoi son message, 4/ et ainsi, on peut calculer (grossièrement) un temps de réponse (récupération du message) réel ici de 22 milli-secondes (2022 – 2000 = 22).

Voilà pour cette très petite introduction aux tests JMS Pub/Sub.

./

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

./

Il s’agissait principalement de mettre des captures d’écrans d’un JMeter « français », d’adapter le texte associé, mais également de corriger des fautes de style ou d’orthographes…

On notera que depuis 2008, la date d’écriture de la première version de ce tutoriel, il n’y a pas eu de changement au niveau JMeter sur la configuration d’un test distribué.

./

Depuis la version 2.4 de JMeter, une nouvelle fonctionnalité permet le changement d’adresse IP source pour les requêtes HTTP transmises par JMeter.

L’intérêt de cette possibilité est (par exemple) de permettre de faire des tests de charges sur des architectures techniques comportant un suivi de session par adresse IP (typiquement au niveau des répartiteurs de charges).

Voici un petit mode d’emploi.

Préparation

Étape 1 : récupérer JMeter (au moins la version 2.5) (ici c’est la 2.5.1 qui est présentée)

Étape 2 : définir et configurer sur sa machine JMeter les adresses IP que l’on veut utiliser dans son test. Pour cela, il faut utiliser la fonctionnalité d’adressage IP secondaire sur la machine JMeter. Il est en effet possible sur un ordinateur de définir plusieurs adresses IP pour une seule carte réseau (appelé IP alias). La machine répondra donc à plusieurs adresses IP sur le réseau (elle sera « pingable » sur plusieurs adresses IP).

• Sous Windows (XP), c’est dans les options avancées de la configuration réseau, au niveau du protocole TCP/IP, paramètres avancées, Adresse IP.
• Sous Linux, soit avec le gestionnaire de connexion (network manager), soit dans les fichiers textes de configuration (ifcfg-ethx:x avec RedHat/CentOS/Fedora ou interfaces dans Debian/Ubuntu).

Étape 3 : créer un fichier texte contenant la liste des adresses IP que vous avez définie. Une adresse IP par ligne.

• 192.168.7.80
• 192.168.7.81
• 192.168.7.82
• 192.168.7.83
• 192.168.7.84
• etc…

Réalisation avec JMeter

Bon, maintenant que les préparations sont terminées, on peut passer à JMeter. Voici le plan de test simple pour mettre en œuvre un exemple simple (une seule requête HTTP).

On note, l’élément de configuration Source de données CSV, qui va permettre de récupérer les adresses IP provenant la liste.

La variable JMeter ADR_IP recevra donc une adresse IP à chaque itération de JMeter. Cette variable sera utilisée dans l’échantillon Requête HTTP dans le champ « Adresse IP source ».

Attention : pour que la fonctionnalité de changement d’adresse IP fonctionne, il faut choisir une Implémentation compatible : soit HttpClient 3.1 ou soit HttpClient 4. Cf. capture ci-dessous.

Voilà, ensuite c’est presque prêt, on ajoute un récepteur de résultats, on configure par exemple le Groupe d’unités à 1-1-10 et on lance.

Dans les logs du serveur Apache (qui est ici testé), on voit le changement d’adresse IP source (la première colonne). Et hop.

Le petit bémol, c’est qu’il n’est pas possible (pour l’instant) de le définir globalement dans un élément Paramètres HTTP par défaut. Il est donc nécessaire de poser la variable qui va faire changer l’adresse IP source dans chaque Requête HTTP. (Un édition/remplacer global dans le fichier JMX avec un editeur de texte le fera en une seule fois.)

./

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

./