Tutoriel pour apprendre à créer et rajouter un script avec JMeter

Antonio Gomes Rodrigues

Après avoir vu dans la première partie l'utilisation d'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.

Pour réagir au contenu de cet article, un espace de dialogue vous est proposé sur le forum. Commentez

- Titre : Tutoriel pour apprendre à créer et rajouter un script avec JMeter

- Auteur : Antonio Gomes Rodrigues

- Parution : 12 octobre 2016

- Licence : Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright ® 2016 Antonio Gomes-Rodrigues. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Scénario à enregistrer

- II. Création du script

- II-A. Préparation du script

- II-B. Enregistrement du script

- II-C. Nettoyage de l'enregistrement

- II-D. Variabilisation

- II-E. Ajout des contrôles

- II-F. Mise en place du reporting

- III. Contrôle du débit

- III-A. Pacing

- III-B. Rendez-vous

- IV. Derniers paramétrages du script

- IV-A. Paramétrage des propriétés du groupe d'unités

- IV-B. Paramétrage de l'environnement cible

- IV-C. Envoi d'email au début et à la fin du test

- IV-D. Chemin du fichier CSV

- V. Exécution du test de charge

- V-A. Test de charge à l'aide du GUI

- V-B. Test de charge en ligne de commande

- V-C. Test de charge distribué

- VI. Analyse des résultats

- VII. Conclusion et remerciements

I - 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 clic sur le lien « Find owner » :

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

II - Création du script

Lançons Jmeter :

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

II-A - 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.

II-B - Enregistrement du script

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

Après enregistrement, on obtient le script suivant :

II-C - Nettoyage de l'enregistrement

Pour commencer, nous allons renommer les noms des contrôleurs Transaction afin qu'ils soient plus parlants :

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.

II-D - 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.

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.

II-E - Ajout des contrôles

Nous allons ajouter des contrôles des réponses :

II-F - 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 de récepteurs, car cela peut être très consommateur en mémoire et peut faire planter JMeter.

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

III - 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 Users.

III-A - 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 six é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 à peu près toutes les minutes.

III-B - Rendez-vous

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

Supposons que nous voulons que trois 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 dix Virtuals Users :

Sur cette capture d'écran, on voit bien que trois Virtuals Users s'attendent pour exécuter la transaction Clients_02_Owner_Information (on voit que trois 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).

IV - 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.

IV-A - 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

IV-B - 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 :

IV-C - Envoi d'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 :

IV-D - 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 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 :

V - 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 côté-là lors des tests.

V-A - 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 threads actifs sera présent en haut à droite. En sélectionnant le récepteur souhaité, on pourra suivre en direct la progression du test :

V-B - 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">

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 sortie standard) :

1. #---------------------------------------------------------------------------

2. # Summariser - Generate Summary Results - configuration (mainly applies to non-GUI mode)

3. #---------------------------------------------------------------------------

4. #

5. # Define the following property to automatically start a summariser with that name

6. # (applies to non-GUI mode only)

7. summariser.name=summary

8. #

9. # interval between summaries (in seconds) default 3 minutes

10. summariser.interval=20

11. #

12. # Write messages to log file

13. summariser.log=false

14. #

15. # Write messages to System.out

16. summariser.out=true

Le résultat sera sous la forme suivante :

1. $ C:\Utils\Jmeter\apache-jmeter-2.6\bin>jmeter.bat -n -t ..\..\PlanDeTest\Formation_PetClinic_06_run.jmx

2. Creating summariser

4. <summary>

5. Created the tree successfully using ..\..\PlanDeTest\Formation_PetClinic_06_run.jmx

6. Starting the test @ Mon May 28 16:20:58 CEST 2012 (1338214858366)

7. Waiting for possible shutdown message on port 4445

8. summary +     4 in   1,5 s =    2,6/s Avg:    20 Min:     3 Max:    70 Err:     0 (0,00 %)

9. summary +    37 in  19,8 s =    1,9/s Avg:     8 Min:     2 Max:    28 Err:     0 (0,00 %)

10. summary =    41 in  21,8 s =    1,9/s Avg:     9 Min:     2 Max:    70 Err:     0 (0,00 %)

11. summary +    38 in  19,7 s =    1,9/s Avg:     8 Min:     4 Max:    22 Err:     0 (0,00 %)

12. summary =    79 in  41,7 s =    1,9/s Avg:     8 Min:     2 Max:    70 Err:     0 (0,00 %)

13. summary +    32 in  22,8 s =    1,4/s Avg:     8 Min:     3 Max:    22 Err:     0 (0,00 %)

14. summary =   111 in  65,1 s =    1,7/s Avg:     8 Min:     2 Max:    70 Err:     0 (0,00 %)

15. summary +    31 in  16,4 s =    1,9/s Avg:     8 Min:     2 Max:    19 Err:     0 (0,00 %)

16. summary =   142 in  81,4 s =    1,7/s Avg:     8 Min:     2 Max:    70 Err:     0 (0,00 %)

17. summary +     8 in   3,5 s =    2,3/s Avg:    16 Min:    14 Max:    26 Err:     0 (0,00 %)

18. summary =   150 in  85,5 s =    1,8/s Avg:     8 Min:     2 Max:    70 Err:     0 (0,00 %)

19. Tidying up ...    @ Mon May 28 16:22:24 CEST 2012 (1338214944144)

20. ... end of run

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

Analysons la premiè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 quatre é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 %.

V-C - 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 un contrôleur qui contrôle les autres instances de JMeter et un ou plusieurs injecteurs qui exécutent 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.

1. #---------------------------------------------------------------------------

2. # Remote hosts configuration

3. #---------------------------------------------------------------------------

5. # Remote Hosts - comma delimited

6. remote_hosts=192.168.0.10,192.168.0.12

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

1. JMETER_HOME\bin\jmeter-server.bat

3. JMETER_HOME/bin/jmeter-server

5. jmeter-server.bat

6. Could not find ApacheJmeter_core.jar ...

7. ... Trying JMETER_HOME=..

8. Found ApacheJMeter_core.jar

9. Created remote object: UnicastServerRef [liveRef: [endpoint:[192.168.56.1:50416](local),objID:[17914e3d:1379528ced9:-7fff, -7848514907573579168]]]

10. 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.

VI - 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.

VII - Conclusion et remerciements

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.

Cet article a été publié avec l'aimable autorisation de la société Aliecom.

Nous tenons à remercier f-leb pour la relecture orthographique, Djibril et Mickaël Baron pour la mise au gabarit.