Présentation de l’outil Apache JMeter – partie 2


Après avoir vu dans la première partie l'utilisation de Apache JMeter, nous allons continuer son apprentissage. Pour cela nous verrons comment enregistrer de manière réaliste (en particulier sur les temps de réponse) un script et comment le lancer.

Nous utiliserons la version 2.6 en français de JMeter.

 

2 - Scénario à enregistrer

Cette fois-ci nous allons utiliser l'application Spring PetClinic

On va scripter ce scénario.

Accès à la page d'accueil

Accès à la page de recherche après un click sur le lien « Find owner »

Accès à la page d'information des clients après un clique sur le bouton « Find Owners »

3 - Création du script

Lançons JMeter.

Comme on peut le voir, la version 2.6 a modernisé l'interface.

3.1 - Préparation du script

Commençons par ajouter l'élément groupe d'unités.

Puis ajoutons tous les éléments de configuration.

Le contrôleur enregistreur nous permettra de stocker les requêtes enregistrées par le proxy.

Ajoutons le proxy.

L'arbre de résultats nous permettra d'avoir les requêtes et réponses échangées (utile pour la variabilisation et l'ajout de contrôles).

Enfin, ajoutons un compteur de temps aléatoire uniforme afin de sauvegarder les temps de pause entre chaque action de l'utilisateur.

3.2 - Enregistrement du script

Il nous reste à lancer l'exécution du proxy et à enregistrer notre script.

Après enregistrement on obtient le script suivant.

3.3 - Nettoyage de l'enregistrement

Pour commencer nous allons renommer les noms des contrôleurs transaction afin qu'ils soient plus parlant.

Puis modifions les valeurs des entêtes du gestionnaire d'entêtes HTTP avec les valeurs enregistrées si cela n'a pas été défini avant.

Exécutons le script une fois.

Comme on peut le voir dans le Rapport agrégé, les temps de réponse ne sont pas bons, car les temps de pause sont inclus dans les temps de réponse.

Pour résoudre ce problème, on peut remplacer les compteurs de temps aléatoire uniforme par des Action test et y reporter la bonne valeur de pause.

Ou sinon exclure les temps de pause dans le calcul du temps de réponse.

Et voilà qui est mieux.

3.4 - Variabilisation

Dans le scénario lorsqu'on cherche un propriétaire, on entre son nom dans le formulaire de recherche. Afin que le test soit plus réaliste, on va variabiliser ce nom.

Nous allons utiliser une source de données CSV.

Ne pas oublier de mettre la bonne variable en entrée pour le formulaire.

La deuxième variabilisation à faire est la requête qui affiche les informations sur le propriétaire.

Si l'on regarde l'arbre de résultats, on remarque que cette requête est le résultat d'une redirection HTTP (HTTP code 302).

Lorsque nous exécutons le script, on remarque que la requête d'affichage des informations du propriétaire est exécutée deux fois (une fois à cause de la redirection et une autre fois, car JMeter lui demande).

On peut en déduire qu'on n’a pas besoin de variabiliser cette requête et qu'il suffit de désactiver la deuxième.

3.5 - Ajout des contrôles

Comme indiqué sur cet article, nous allons ajouter des contrôles des réponses.

3.6 - Mise en place du reporting

Notre script est presque fini et il nous reste à ajouter des récepteurs afin d'avoir du reporting.

Attention aux choix du type et du nombre des récepteurs, car cela peut être très consommateur en mémoire et peu faire planter JMeter.

Nous allons nous contenter d'un Rapport agrégé.

4 - Contrôle du débit

À ce stade on pourrait utiliser directement notre script. Mais dans certains cas il est important de contrôler la charge cible et donc le débit que l'on veut et de synchroniser un certain nombre de Virtual User.

4.1 - Pacing

Commençons par le contrôle de la charge cible.

Un moyen simple est d'ajouter un contrôleur de débit constant.

Une fois cela fait, il suffit de définir le nombre d'échantillons par minute. Dans notre cas nous avons 6 échantillons (3 Action test + 3 requêtes HTTP).
Donc pour avoir une itération du script par minute il faut mettre la valeur 6 pour le débit ciblé.

Si l'on veut une itération toutes les trente secondes, la bonne valeur est douze et ainsi de suite.

Afin de vérifier que cela marche, exécutons le script.

On voit bien qu'il y a une itération du script un peu près toutes les minutes.

4.2 - Rendez-vous

Afin qu'un certain nombre de Virtual User se synchronise pour une certaine action, il faut ajouter un compteur de synchronisation.

Supposons que nous voulons que 3 Virtual Users s'attendent avant l'affichage des informations du propriétaire (transaction Clients_02_Owner_Information).

Afin de vérifier que cela est bien paramétré, lançons un test avec 10 Virtuals Users.

Sur cette capture d'écran, on voit bien que 3 Virtuals Users s'attendent pour exécuter la transaction Clients_02_Owner_Information (on voit que 3 transactions Clients_00_HomePage sont réalisées juste après par les mêmes Virtual Users et avant les transactions Clients_02_Owner_Information des autres Virtual Users car prenant moins de temps).

5 - Derniers paramétrages du script

Afin de faciliter l'exécution en ligne de commande du script et l'exécution sur différentes plateformes cibles, nous allons réaliser les derniers paramétrages de notre script.

5.1 - Paramétrage des propriétés du groupe d'unités

Afin d'avoir accès en ligne de commande aux propriétés du groupe d'unités nous allons utiliser la fonction ${__P(xxx,yyy)} avec xxx le nom de la variable et yyy sa valeur par défaut.

Voilà le résultat.

En ligne de commande, il suffira d'exécuter JMeter avec le paramètre J et les valeurs souhaitées.

Par exemple.

 jmeter -n -l resultats.csv -t scenario.jmx -JnbUnites=10 -JrampUp=20 -JnbIterations=100

5.2 - Paramétrage de l'environnement cible

Toujours avec la fonction ${__P(xxx,yyy)}, paramétrons l'environnement cible à l'aide de l'élément Paramètres HTTP par défaut.

Deux autres solutions sont possibles, soit en ajoutant des variables prédéfinies dans l'élément « Plan de test », soit avec un élément Variables prédéfinies.

5.3 - Envoi de email au début et à la fin du test

Lors d'un lancement d'un test de charge, on n'est pas toujours devant le PC et donc il peut être intéressant d'envoyer un email au début et à la fin du test.
Pour cela nous allons utiliser les éléments Groupe d'unités de début et Groupe d'unités de fin. Comme leur nom l'indique, ils nous permettent de réaliser des actions avant et après le test.

Ajoutons à chacun des deux éléments précédents un élément échantillon SMTP et configurons-le afin d'envoyer un email à la bonne adresse.

5.4 - Chemin du fichier CSV

Afin de pouvoir lancer le plan de test sous Windows ou sous Linux, on va configurer automatiquement le chemin du fichier CSV qu'on utilise au bon format.

Le principe comme expliqué sur le blog de Milamber est d'utiliser un élément Echantillon BeanShell afin de détecter le système d'exploitation hôte et de le mettre dans une propriété JMeter à l'aide du script BeanShell suivant.

String sOs = System.getProperty(« os.name »).toLowerCase(); 
 if (sOs.contains(« windows »)) { 
 props.setProperty(« CSV_Path », « C:/Test/ »); 
 } else { 
 // Linux/Unix/Mac 
 props.setProperty(« CSV_Path », « /tmp/ »); 
 }

Ne pas oublier de modifier l'élément Source de données CSV.

6 - Exécution du test de charge

Tout est prêt pour que l'on puisse faire un test de charge.

Ne pas oublier de superviser les injecteurs et les instances de JMeter afin de s'assurer qu'il n'y a pas de problème de ce coté la lors des tests.

6.1 - Test de charge à l'aide du GUI

Si la charge cible n'est pas énorme, le test de charge peut être fait à l'aide de l'interface graphique de JMeter.

Pendant l'exécution du test, le nombre de thread actifs sera présent en haut à droite. En sélectionnant le récepteur souhaité, on pourra suivre en direct la progression du test.

6.2 - Test de charge en ligne de commande

Si la puissance de notre injecteur est trop limitée pour supporter la charge, on peut lancer JMeter en ligne de commande.

Pour cela il faut utiliser la ligne de commande suivante.

jmeter -n -t<script type="text/javascript">// <![CDATA[
.jmx

Le paramètre -n permet l’activation du mode texte.

Afin de suivre la progression du test, modifier le fichier JMETER_HOME/bin/user.properties en ajoutant/modifiant les lignes suivantes (ici on va demander à JMeter d'afficher des informations toutes les 20 s sur la sortir standard).

#--------------------------------------------------------------------------- 
# Summariser - Generate Summary Results - configuration (mainly applies to non-GUI mode) 
#--------------------------------------------------------------------------- 
# 
# Define the following property to automatically start a summariser with that name 
# (applies to non-GUI mode only) 
summariser.name=summary 
# 
# interval between summaries (in seconds) default 3 minutes 
summariser.interval=20 
# 
# Write messages to log file 
summariser.log=false 
# 
# Write messages to System.out 
summariser.out=true

Le résultat sera sous la forme suivante.

C:\Utils\Jmeter\apache-jmeter-2.6\bin>jmeter.bat -n -t ..\..\PlanDeTest\Formation_PetClinic_06_run.jmx 
Creating summariser
 
<summary> 
Created the tree successfully using ..\..\PlanDeTest\Formation_PetClinic_06_run.jmx 
Starting the test @ Mon May 28 16:20:58 CEST 2012 (1338214858366) 
Waiting for possible shutdown message on port 4445 
summary +     4 in   1,5 s =    2,6/s Avg:    20 Min:     3 Max:    70 Err:     0 (0,00 %) 
summary +    37 in  19,8 s =    1,9/s Avg:     8 Min:     2 Max:    28 Err:     0 (0,00 %) 
summary =    41 in  21,8 s =    1,9/s Avg:     9 Min:     2 Max:    70 Err:     0 (0,00 %) 
summary +    38 in  19,7 s =    1,9/s Avg:     8 Min:     4 Max:    22 Err:     0 (0,00 %) 
summary =    79 in  41,7 s =    1,9/s Avg:     8 Min:     2 Max:    70 Err:     0 (0,00 %) 
summary +    32 in  22,8 s =    1,4/s Avg:     8 Min:     3 Max:    22 Err:     0 (0,00 %) 
summary =   111 in  65,1 s =    1,7/s Avg:     8 Min:     2 Max:    70 Err:     0 (0,00 %) 
summary +    31 in  16,4 s =    1,9/s Avg:     8 Min:     2 Max:    19 Err:     0 (0,00 %) 
summary =   142 in  81,4 s =    1,7/s Avg:     8 Min:     2 Max:    70 Err:     0 (0,00 %) 
summary +     8 in   3,5 s =    2,3/s Avg:    16 Min:    14 Max:    26 Err:     0 (0,00 %) 
summary =   150 in  85,5 s =    1,8/s Avg:     8 Min:     2 Max:    70 Err:     0 (0,00 %) 
Tidying up ...    @ Mon May 28 16:22:24 CEST 2012 (1338214944144) 
... end of run

Les lignes commençant par « summary + » sont les statistiques au moment T et celles commençant par « summary = » sont les statistiques aggrégés depuis le début du test.

Analysons la preimère ligne : summary +     4 in   1,5 s =    2,6/s Avg:    20 Min:     3 Max:    70 Err:     0 (0,00 %)

On constate que depuis le dernier affichage des statistiques (ici depuis le lancement du test) il y a eu 4 échantillons exécutés durant les 1,5 s avec un débit de 2,6 échantillons par seconde en moyenne. La moyenne des temps de réponse est de 20 ms avec un minimum de 3 ms, un maximum de 70 ms et un taux d'erreur de 0 %.

6.3 - Test de charge distribué

Si cela n'est toujours pas suffisant, on peut faire un test de charge distribué (en mode graphique ou en mode texte).

En mode distribué, on a contrôleur qui contrôle les autres instances de JMeter et un ou plusieurs injecteurs qui exécute le plan de test.

Le processus pour lancer un test de charge distribué avec JMeter est le suivant.

1. Déclarer/vérifier que les injecteurs sont bien définis dans le fichier JMETER_HOME/bin/user.properties

#--------------------------------------------------------------------------- 
# Remote hosts configuration 
#--------------------------------------------------------------------------- 
 
# Remote Hosts - comma delimited 
remote_hosts=192.168.0.10,192.168.0.12

2. Lancer en mode serveur les JMeters présents sur les injecteurs.

JMETER_HOME\bin\jmeter-server.bat 
 
JMETER_HOME/bin/jmeter-server
jmeter-server.bat 
Could not find ApacheJmeter_core.jar ... 
... Trying JMETER_HOME=.. 
Found ApacheJMeter_core.jar 
Created remote object: UnicastServerRef [liveRef: [endpoint:[192.168.56.1:50416](local),objID:[17914e3d:1379528ced9:-7fff, -7848514907573579168]]] 
Starting the test on host 192.168.0.10 @ Mon May 28 22:35:18 CEST 2012 (1338237318520)

3. Lancer le JMeter présent sur le contrôleur

jmeter.bat -n -r -X -t PlanDeTest\Formation_PetClinic_06_run.jmx

Si vous avez bien configuré vos récepteurs, il ne reste plus qu'à analyser les résultats du test.

7 - Analyse des résultats

Maintenant que nous avons des résultats, il existe plusieurs solutions afin de traiter toutes ces données.

On peut analyser les résultats avec JMeter, des tableurs, des outils de statistique, avec Access et mon préféré avec des outils de business intelligence.

Quelques captures d'écran pour voir les possibilités de ces outils.

8 - Conclusion

Grâce à cette partie de notre tutoriel sur JMeter nous avons pu aller plus loin dans notre apprentissage et commencer à voir la puissance de JMeter.

Pour aller encore plus loin, Aliecom organise une formation sur les tests de charge qui reprend et complète cette partie.

// ]]>

4 réponses à to “Présentation de l’outil Apache JMeter – partie 2”

Laisser un commentaire

Merci d'effectuer cette opération simple pour valider le commentaire *

Mots-clés
RSS Feed