[Nouveauté du 07/08/2011, voir ce billet : nouvelle version de ce tutoriel avec JMeter 2.5 et Tomcat 7]
Dans les tutoriels JMeter précédents, nous avons vu que JMeter est un bon outil pour effectuer des tirs de charge. JMeter sait faire d’autres choses.
Je vous propose de voir comment on peut utiliser JMeter pour superviser un Tomcat dans sa version 5.5.
Pour cela, nous allons suivre le mode d’emploi disponible depuis le site de documentation JMeter :
http://jakarta.apache.org/jmeter/usermanual/build-monitor-test-plan.html
Mais avec quelques légères adaptations.
Le pré-requis est bien entendu d’avoir installé un serveur Tomcat (sous Unix/Linux ou Windows) avec un Java JDK.
Éditer le fichier de configuration des utilisateurs :
[/opt/tomcat/conf]# vi tomcat-users.xml
Le fichier ressemble à cela :
<?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="tomcat"/> <role rolename="role1"/> <user username="both" password="tomcat" roles="tomcat,role1"/> <user username="tomcat" password="tomcat" roles="tomcat"/> <user username="role1" password="tomcat" roles="role1"/> </tomcat-users>
Le modifier pour avoir :
<?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="manager"/> <role rolename="tomcat"/> <role rolename="admin"/> <role rolename="role1"/> <user username="both" password="tomcat" roles="tomcat,role1"/> <user username="tomcat" password="tomcat!!" roles="tomcat,admin,manager"/> <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://svr-tomcat:8080/manager/status
Une fenêtre de saisie de login / mot de passe apparaît :
Ensuite, le navigateur fait apparaître le statut d’exécution de Tomcat :
Bon, tout est OK. Passons au paramétrage de JMeter.
Après avoir démarré JMeter, on commence par ajouter un Thread Group au niveau du Test Plan.
Dans la configuration du Thread Group, on choisira le Loop Count à Forever (en cochant la case) afin d’avoir un outil de monitoring qui s’arrête seulement quand l’opérateur le décide.
On notera qu’il est possible aussi d’utiliser la programmation de fonctionnement (via Scheduler) afin de synchroniser la supervision du Tomcat avec par exemple l’exécution d’un tir de charge.
On ajoute ensuite un élément HTTP Authorization Manager afin de gérer l’authentification demandée par Tomcat pour voir le statut du serveur.
Dans la configuration du HTTP Authorization Manager, on ajoutera dans :
- le champ Usernane : tomcat (en fonction du paramétrage du fichier tomcat-users.xml)
- le champ Password : tomcat!! (en fonction du paramétrage du fichier tomcat-users.xml)
- Les autres champs sont laissés à vide.
On continue en ajoutant un élément HTTP Request pour effectuer la requête HTTP permettant de demander le statut du serveur.
Dans la configuration de l’élément HTTP Request, on modifiera la valeur des champs suivants :
- Name : Server Status
- Server Name or IP : svr-tomcat (ou l’adresse IP du serveur)
- Port Number : 8080
- Path : /manager/status
- Send Parameters With the Request : ajout d’un élément
- Name : XML et Value : true.
- Sans oublier à la fin, de cocher le champ Use as Monitor.
Afin de demander le statut du serveur régulièrement, on ajoute un élément Constant Timer qui laissera un intervalle de temps entre chaque demande. Attention à ne pas le mettre trop souvent car l’appel à cette requête de statut consomme une unité d’exécution sur le Tomcat.
On paramétra l’élément Constant Timer pour une fréquence de 5000 ms (5s) de rafraichissement des données de monitoring.
Il ne reste plus qu’à ajouter l’élément Monitor Results pour voir de manière graphique l’état du serveur Tomcat.
Ensuite on passe à l’exécution d’un tir de test sur le serveur Tomcat. Pour cela, j’ai repris le tir de charges par palier, tout en supervisant le Tomcat.
Concernant les paramètres de JVM, j’ai réduit la mémoire maximum allouée à 128 Mo afin surcharger volontairement le serveur. Dans le fichier catalina.sh (dans TOMCAT_HOME/bin), j’ai ajouté la ligne suivant au début du fichier :
JAVA_OPTS= »$JAVA_OPTS -server -Xms64M -Xmx128M »
Voici l’affichage de l’état de santé du serveur Tomcat à un instant T :
Et voici le graphique de performance du serveur Tomcat durant le tir de charge.
Quelques explications du graphique :
On retrouve donc les deux paliers (50 utilisateurs et 100 utilisateurs). La courbe des threads (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 commence à être chargé dès la phase de montée de 50 à 100 VU. Ensuite à 100 utilisateurs, Tomcat est surchargé, le nombre d’unités d’exécution est au maximum régulièrement, la mémoire JVM enchaîne les passage de GC. La retombée subite à 50 VU redonne tout de suite la santé au serveur Tomcat.
Voilà pour ce petit tutoriel sur la supervision d’un Tomcat 6. Bon courage.
./
Bonjour,
Tout d’abord merci pour tous ces tutoriel.
Je bloque cependant sur le monitoring Tomcat.
Je souhaite lancer mon test de charge en ligne de commande et récupérer à la fin du tir le graph ci-dessus. Est-ce possible ?
Merci
Bonjour,
Le mieux sera d’avoir deux JMeter (sur la même machine ou sur deux machines différentes).
Une pour la supervision du Tomcat pendant le tir
Une en ligne de commande pour le tir.
Sinon, avant de lancer ton tir, quand tu définis ton scénario, tu peux simplement définir un fichier (avec le chemin) dans le champ Filename du récepteur Moniteur Tomcat, et cliquer sur le bouton Configure, pour tout cocher.
Ensuite tu lances ton tir en ligne de commande.
A la fin du tir, tu peux ouvrir JMeter sur un scénario vide, puis ajouter un récepteur Moniteur Tomcat, et cliquer sur le bouton Parcourir pour ouvrir le fichier défini avant le tir. Normalement les courbes vont se dessiner.
A+
Milamber
Bonjour,
Merci mais malheureusement cela ne fonctionne pas.
On dirai que le « Moniteur de résultat » est pratiquement le seul récepteur à ne pas charger les fichiers jtl.
Deception; je vais devoir développer ma propre sonde tomcat…