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 !

Ce tutoriel est de Philippe Mouawad, membre PMC de JMeter et développeur actif de JMeter. Son tutoriel « JMeter Switch Controller ou comment contrôler les pourcentages d’échantillons » permet de répondre à une problématique assez récurrente lorsque l’on a un plan de test de charge avec une répartition des actions utilisateurs en pourcentages (50% font de la consultation, 25% des commandes, 25% des recherches par exemple).

Merci pour ce tutoriel.

Pour commencer cette nouvelle année, et à la vue des quelques articles et tutoriels francophones sur JMeter qui pointent de temps en temps sur le web, j’ouvre une page « Liens JMeter » sur ce blog afin de lister ces articles et tutoriels.

Sur cette page, donc, j’ai placé les liens que j’ai pu recenser depuis quelques années sur ce blog. J’espère que cette page aura une liste qui s’allongera de plus en plus !

Tout d’abord, un article de Thibault Duchateau pour savoir comment générer au lancement de JMeter un fichier qui servira de source de données CSV dans un test. La recette est à base de Groupes d’unités de début et de BeanShell.

L’autre article est d’Antonio Gomes-Rodrigues, auteur de plusieurs tutoriels JMeter / Performances sur Developpez.com, qui présente l’utilisation de JMeter pour réaliser un test d’une application JSF, avec la particularité du suivi utilisant le fameux VIEWSTATE.

Merci à leur auteur respectif pour ces articles qui viennent enrichir l’écosystème documentaire de 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)}

Cette nouvelle version cible principalement la correction d’anomalies sur l’implémentation HTTPClient 4 pour la requête HTTP, l’utilisation de la fonctionnalité de téléchargement parallèles des ressources associées à une page et des anomalies dans des conditions particulières du Contrôleur Si.

Il y a quelques nouveautés au niveau de la requête WebService (SOAP) d’un point de vue convivialité et interface utilisateur (voir ce tutoriel)

On notera qu’il reste des anomalies du coté de la fonctionnalité de téléchargement des ressources associées à une page (voir les bugs 51918 et 51919). Ces bugs sont en cours de corrections (le 51918 est déjà corrigé), et une nouvelle version de JMeter arrivera rapidement pour palier à ces anos.

J’ajouterai que pour cette nouvelle version, un nouveau contributeur (Philippe M.) très actif a fait son apparition du coté des développeurs JMeter. Et comme il est basé en France (et sait lire le français), j’en profite pour le remercier pour ses contributions effectuées et à venir.

Pour finir, je vous recommande de passer sur la version 2.5.1 si vous êtes sur la 2.5 (en particulier si vous utilisez les HTTPClient 4).

./

Cette mise à jour pour avoir des captures d’écrans en français, et également pour montrer la nouvelle présentation de la requête WebService SOAP dans JMeter. En effet avec la (future) version 2.5.1 de JMeter, quelques changements pour rendre plus jolie et conviviale cette requête ont été fait.

Par ailleurs, cette version 2.5 a un sens particulier pour moi, puisque j’ai joué le rôle du « release manager » pour elle. Ainsi j’ai réalisé le processus de « délivrance » de la nouvelle version (vote de release, création des archives à télécharger, signature numérique, mise à jour du site Jakarta/JMeter, et annonce).

Voici un petit tour des principales nouveautés :

Nouvelle implémentation Requête HTTP

Avant JMeter possédait deux implémentations différentes pour réaliser une Requête HTTP : Java et HTTPClient version 3.1.

Avec la version 2.5, il y a trois, toujours les deux premières plus une nouvelle « HTTPClient4 » qui dont repose sur la version 4.x de l’API HTTPClient d’Apache.

Lors de cet ajout, les deux échantillons requêtes HTTP existants ont été fusionné en un seul, et une nouvelle liste déroulante (cf capture) dans la configuration de la Requête HTTP permet de choisir l’implémentation. Par défaut, c’est « vide », et cela correspond à l’implémentation historique Java.

• NB1. Il est possible de changer l’implémentation par défaut à utiliser par le Proxy JMeter, via le paramètre jmeter.httpsampler dans le fichier jmeter.properties.
• NB2. Théoriquement la meilleure implémentation en termes de qualité/performance est HTTPClient4.

Récupération parallèle des ressources d’une page

Une nouvelle fonctionnalité ajoutée également dans la Requête HTTP, est la possibilité de récupérer en parallèle les ressources associées à une page (i.e. les css, js, images, etc), via un pool d’unités d’exécution dont la taille est paramétrable (cf. capture).

Cette nouvelle fonctionnalité permet entre autre de « simuler » mieux le comportement des navigateurs actuels qui parallélisent la récupération des éléments d’une page (pour un affichage plus rapide).

Deux nouveaux Moteurs d’utilisateurs font leur apparition :

• le Groupe d’unités de début, qui permet d’avoir un groupe d’unités qui sera lancé une seule fois au début d’un tir, et ceux avant les groupes d’unités « normaux »
• le Groupe d’unités de fin, qui est le penchant du début, mais pour la fin d’un tir.

L’idée ici, et de permettre d’exécuter un scénario avant/après le vrai tir, par exemple de préparation de données de tir ou de récupérer des métriques de test en fin de tir.

Démarrer l’itération suivante

Dans la configuration du Groupe d’unités, au niveau de l’action à faire en cas d’erreur dans un scénario, une nouvelle option apparaît : « Démarrer l’itération suivante », qui permet donc à l’unité de test, en cas d’erreur, de revenir au début du scénario pour un nouveau tour.

Taille de la réponse

Dans l’arbre de résultats, JMeter affiche maintenant le détail sur la taille de la réponse reçue pour une requête HTTP (ainsi que la bonne valeur). Avant en effet, la taille donnée était la taille décompressé du corps de la réponse. C’est-à-dire que les entêtes n’étaient pas comptabilisées, et en cas de réponse compressée (le fameux mod_deflate sur Apache par exemple), JMeter ne donnait pas la bonne taille.

Maintenant donc, il y a le détail, et c’est la taille (à l’octet près) précise de la réponse qui est donnée.

Versions Tableaux dans l’arbre de résultats

Une version « tableau » existe maintenant pour afficher les éléments de requête dans un échantillon HTTP. Cela aide pour le copier/coller vers un outil de bureautique (pour les rapports par exemple)

La version tableau pour l’onglet Résultat de l’échantillon (qui existe depuis la version 2.4) a reçu également une amélioration. Il est désormais possible de double-cliquer sur une cellule du tableau pour faire apparaître une fenêtre contenant la valeur. Utile pour les valeurs longues. Cf Captures.

Fragment d’éléments

Un nouveau type d’éléments fait son apparition : le Fragment d’éléments. Il permet d’avoir une section dans son scénario qui ne sera pas exécuter par JMeter. Pratique pour mettre de coté des échantillons sans les désactiver ou bien (et surtout) pour le fameux JMeter Proxy afin qu’il soit sauvegarder avec son script.

Le Fragment d’éléments ne fait rien, il empêche juste JMeter d’exécuter ses éléments fils.

Ici un exemple d’utilisation du Fragment d’éléments pour « stocker » la section Proxy dans son Plan de test.

Requête SMTP

La Requête SMTP a été améliorée, il est possible d’envoi des mails avec JMeter avec quasiment toutes les variantes possibles, notamment pour les connexions en SSL ou en StartTLS.

Requête JMS

Niveau Requêtes JMS, il est maintenant possible d’avoir des noms de Destination « variables » durant le tir. Avant mettre une variable JMeter dans le champ Destination ne fonctionnait pas car, JMeter ouvrait la connexion vers la file de Destination avant le lancement du tir. Maintenant il y a le choix, soit le comportement classique (Au démarrage), soit avant chaque exécution d’échantillon.

Assertion Taille

Une petite amélioration sur l’Assertion Taille : il est possible maintenant de vérifier la taille sur des « sous-parties » de la réponse, par exemple les entêtes ou le corps seulement de la réponse.

Il a d’autres petites nouveautés dans cette nouvelle version de JMeter, ainsi qu’une part importante de bogues corrigés. Vous pouvez voir le détail ici.

Je vous encourage à utiliser cette nouvelle version.

NB. Les fichiers scripts (jmx) créés / enregistrés avec JMeter 2.5 ne sont plus lisibles par les versions précédentes de JMeter. Bien entendu, les fichiers créés / enregistrés avec les versions précédentes sont lisibles par la version 2.5.

./

Nous allons donc utiliser JMeter pour supervision le fonctionnement d’un serveur Tomcat à travers son interface de statut.

Le pré-requis est bien entendu d’avoir à disposition un serveur Tomcat (sous Unix/Linux ou Windows) tournant sur un Java JDK.

On va commencer par « ouvrir » le service de statut du Tomcat. Pour cela, éditer le fichier de configuration des utilisateurs

vi <TOMCAT_HOME>/conf/tomcat-users.xml

Le fichier contient une section tomcat-users (en commentaire) comme ceci :

<tomcat-users>
<!--
  <role rolename="tomcat"/>
  <role rolename="role1"/>
  <user username="tomcat" password="tomcat" roles="tomcat"/>
  <user username="both" password="tomcat" roles="tomcat,role1"/>
  <user username="role1" password="tomcat" roles="role1"/>
-->
</tomcat-users>

Il faut modifier cette section pour ajouter les rôles admin, manager, manager-gui et les affecter à l’utilisateur « tomcat ». Ce qui donne quelque chose comme cela :

<tomcat-users>
  <role rolename="tomcat"/>
  <role rolename="role1"/>
  <role rolename="admin"/>
  <role rolename="manager"/>
  <role rolename="manager-gui"/>
  <user username="tomcat" password="tomcat" roles="tomcat,admin,manager,manager-gui"/>
  <user username="both" password="tomcat" roles="tomcat,role1"/>
  <user username="role1" password="tomcat" roles="role1"/>
</tomcat-users>

Vérifions que la supervision Tomcat fonctionne, pour cela on démarre son serveur Tomcat, et avec un navigateur, on saisie l’URL :

http://debiansvr.milamberspace.net:8080/manager/status?XML=true

où debiansvr.milamberspace.net est le nom ou l’adresse IP de son Tomcat.

Une fenêtre d’authentification apparaît dans le navigateur, saisir le login tomcat et le mot de passe associé (ici tomcat).

Ensuite, le navigateur fait apparaître le statut d’exécution de Tomcat :

NB. dans l’URL, le paramètre XML=true (attention au respect de la casse), permet un affichage épuré, nécessaire à JMeter pour le fonctionnement de la supervision Tomcat.

NB2. on remarquera également qu’il y a par défaut deux connecteurs. Le connecteur AJP utilisé en général le module mod_jk couplé à un Apache HTTPD frontal, et le connecteur HTTP qui lui est le connecteur généralement utilisé pour les accès directs à Tomcat via le port 8080. Noter le nom de ces connecteurs, car il faudra indiquer à JMeter lequel on veut superviser.

Passons au paramétrage de JMeter.

Après avoir démarré JMeter, on commence par ajouter un Groupe d’unités au niveau du Plan de test.

Dans la configuration du Groupe d’unités, on choisira le Nombre d’itérations à Infini (en cochant la case) afin d’avoir un outil de supervision qui s’arrête seulement quand l’opérateur le décide.

On ajoute ensuite un élément Gestionnaire d’autorisation HTTP afin de gérer l’authentification demandée au niveau du navigateur par Tomcat pour voir le statut du serveur.

Dans la configuration du Gestionnaire d’autorisation HTTP, on ajoutera dans :

• Le champ Nom d’utilisateur : tomcat (en fonction du paramétrage du fichier tomcat-users.xml)
• Le champ Mot de passe : tomcat (en fonction du paramétrage du fichier tomcat-users.xml)
• Les autres champs sont laissés vide.

 On continue en ajoutant un échantillon Requête HTTP pour effectuer la requête permettant de demander le statut du serveur.

Dans la configuration de l’élément Requête HTTP, on modifiera la valeur des champs suivants :

• Nom : Statut Tomcat
• Nom ou adresse IP : debiansvr.milamberspace.net (ou l’adresse IP du serveur)
• Port : 8080
• Chemin : /manager/status
• Envoyer les paramètres avec la requête : Clic que le bouton Ajouter
• Nouvelle valeur : Nom : XML et Valeur : true.
• Sans oublier à la fin, de cocher le champ Utiliser comme moniteur.

Afin de demander le statut du serveur régulièrement, on ajoute un élément Compteur de temps fixe qui laissera un intervalle de temps entre chaque demande.

On paramètre l’élément Compteur de temps fixe pour une fréquence de 5000 ms (5s) de rafraîchissement des données de monitoring. 

Il ne reste plus qu’à ajouter le récepteur Moniteur de connecteurs pour suivre de manière graphique l’état du serveur Tomcat.

Dans le champ situé en bas du Moniteur de connecteurs, on indique le début du nom du connecteur que l’on souhaite superviser. Ici, je veux voir le connecteur HTTP, donc la valeur du champ est :

"http-

Noter les guillemets ouvrantes dans son début de nom (particularité Tomcat 7).

Au final, notre arbre JMeter est le suivant :

Et voilà, on peut démarrer le début de la supervision, en lançant JMeter via le menu habituel.

Le petit carré vert en haut à droite de JMeter nous montre que la supervision est active.

Voici l’affichage de l’état de santé du serveur Tomcat à un instant T :

Et voici le graphique de performance du serveur Tomcat durant un petit tir de charge en deux paliers que j’ai réalisé sur ce serveur.

Quelques commentaires du graphique :

• On retrouve donc les deux paliers. La courbe des unités d’exécution de Tomcat reflète assez bien la charge du serveur par rapport au nombre d’utilisateurs simulés.

• Le serveur Tomcat est « en forte activité » dès le début du tir.

• La mémoire JVM enchaîne les passages du Garbage collector (l’aspect dent-de-scie).

Voilà pour ce petit tutoriel sur la supervision d’un Tomcat 7. Bon courage.

Remarque, il est tout à fait possible de superviser plusieurs serveurs Tomcat avec le même script. Pour cela on ajoute autant de Requête HTTP agissant en tant que moniteur de connecteurs, que de serveurs Tomcat à superviser.

./

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.