Tuto : enregistrer des scénarios pour ses tirs de performance avec JMeter

JMeter c’est quoi ?

JMeter est un outil open source permettant d'effectuer des tests de performance d'applications et de serveurs selon différents protocoles ainsi que des tests fonctionnels. Il est développé au sein de la Fondation Apache.

JMeter est entièrement écrit en Java, ce qui lui permet d'être utilisé sur tout système d'exploitation supportant une machine virtuelle JavaLangage de développement très populaire ! (JVM).

Il permet notamment d’enregistrer des scénarios sur des applications et de simuler le comportement de plusieurs utilisateurs agissant de manière simultanée sur celles-ci. Il mesure le temps de réponse de chaque requête et produit des statistiques de ces temps de réponse.

Pourquoi faire des tirs de performance ?

Les tirs de performance sont utiles si l’on souhaite s’assurer que les ressources allouées pour notre application sont cohérentes par rapport à la charge qu’elle devra subir. Cela permet de connaître le point à partir duquel l’application n’est plus capable de répondre et donc de déterminer si celui-ci est satisfaisant par rapport aux attentes.

Il est parfois compliqué de faire intervenir un grand nombre d’utilisateurs en simultané avant une mise en production, JMeter permet donc de le simuler simplement. Nous allons voir les étapes à suivre dans ce tuto, c'est parti !

Étape 1 - Enregistrer un scénario

Pour faire des tirs de performance, il faut d’abord définir un ou plusieurs parcours que pourrait faire un utilisateur sur l’application. Ces scénarios seront alors enregistrés sur JMeter et rejoués pour un nombre variable d’utilisateurs.

Voici comment procéder :

Pour ce tutoriel, nous utiliserons la version 5.4.3 de JMeter.

Mise en place du proxy sur JMeter

La première étape pour l’enregistrement des scénarios est de mettre en place la configuration permettant d’intercepter toutes les requêtes effectuées par l’application que l’on souhaite tester.

Pour cela, nous allons commencer par créer un ThreadGroup et ajouter un Recording Controller qui permettra de stocker l’ensemble des requêtes de notre scénario. 

 

Nous allons ensuite créer les éléments permettant de lancer notre proxy pour intercepter les requêtes. Pour cela, on ajoute un HTTP(s) Test Script Recorder en lui ajoutant un objet View Results Tree qui va nous permettre de voir le détail de toutes les requêtes interceptées (le View Results Tree est également intéressant pendant les phases de tests pour comprendre pourquoi un appel ne fonctionne pas par exemple). 

 

Par défaut le port du proxy est le 8888, il est possible de le modifier en cliquant sur votre HTTP(S) Test Script Recorder et en changeant la valeur de Port dans Global Settings.

Une fois cette configuration mise en place, on peut lancer le proxy en cliquant HTTP(S) Test Script Recorder puis sur le bouton Start. Un message apparaît alors nous indiquant qu’un certificat a été généré. Il s’agit du certificat de JMeter auquel il faut se fier pour que nous puissions lancer notre navigateur ou application en passant par le proxy. À noter que JMeter utilise sa propre JVM et que donc le certificat généré doit être validé pour cette JVM et non au niveau de Windows ou MacOS. 

Une pop-up s’affiche ensuite avec un bouton stop permettant d’arrêter votre proxy. Cela signifie qu’il est bien lancé. 

Utiliser le proxy sur un navigateur (exemple avec Google Chrome)

Une fois votre certificat validé, vous pouvez lancer votre application en spécifiant le port du proxy afin que tous vos appels transitent par celui-ci.

Prenons un exemple sur Google Chrome (mais cela est possible sur tous les navigateurs) :

• Allez dans vos paramètres et taper « proxy » dans la barre de recherche.
• Cliquez sur « Accéder aux paramètres de proxy de votre ordinateur » pour accéder à vos paramètres sur votre système d’exploitation.
• Saisissez les informations de votre proxy (ici localhost sur le port 8888)
• Enregistrez
• Vous êtes prêt à enregistrer vos scénarios ! 
  
   
  

Voir les enregistrements sur JMeter

L’ensemble des appels interceptés par le proxy apparaîtront dans votre Recording Controller de la manière suivante : 

Ce sont ces enregistrements qui seront rejoués. Il est possible de les modifier pour ajouter notamment des variables ou changer le nombre de threads utilisé pour les tests.

Étape 2 - Définir les variables

Sur JMeter, il est possible de définir des variables pour vos tests de performance. Celles-ci peuvent être utiles pour définir un login d’utilisateur, un path vers un fichier ou autres paramètres qui seront utilisés dans vos appels et qui peuvent être différents de ceux que vous avez enregistrés.

Il y a plusieurs façons de définir des variables.

Ajouter une User Defined Variables

La manière la plus simple pour définir des variables est d’ajouter une User Defined Variable. Pour cela il suffit de créer l’élément comme suit et d’ajouter une ou plusieurs variables (en cliquant sur Add en bas de l’écran) qui seront accessibles partout dans vos enregistrements. 

 

Via un fichier CSV

Il est également possible de passer un fichier CSV en entrée contenant l’ensemble des variables que vous souhaitez utiliser pour vos scénarios. Cette utilisation est pratique pour simuler des utilisateurs différents. On peut alors avoir une ligne par utilisateur contenant les informations de chacun.

Pour ajouter un fichier CSV en entrée, il suffit de créer une nouvelle configuration, CSV Data Set Config, et de lui spécifier le path du fichier, les noms des variables pour chaque ligne, et le séparateur. 

 

À noter que lors du lancement des scénarios sur plusieurs threads, chaque thread prendra la ligne suivante dans le CSV.

Via une RegExp

Une autre façon de définir des variables est de le faire avec un RegExp. Cette méthode peut être utile dans vos scénarios notamment si vous avez besoin d’une information qui sera récupérée lors de ceux-ci.

Pour définir une variable de cette façon, il faut configurer un Regular Expression Extractor au niveau de l’appel que vous avez enregistré et lui indiquer le nom de votre variable ainsi que la RegExp pour l’extraire. Il est possible d’extraire cette variable de plusieurs endroits que vous retrouverez dans le menu Field to check, le plus intéressant étant le Body. 

 

Il est également possible d’ajouter une configuration Debug PostProcessor pour permettre de voir l’ensemble des variables stockées, et de voir si votre RegExp a bien fonctionné (vous pouvez laisser les valeurs par défaut à sa création).

Vous retrouverez ce détail dans le ViewResult Tree lors du lancement de vos scénarios. 

Accéder à vos variables

Pour accéder à vos variables dans vos enregistrements, il suffit de les appeler de la façon suivante :

${VOTRE_VARIABLE}

Ensuite, JMeter se chargera de remplacer cette valeur par la valeur de la variable lors du lancement de votre scénario. Vous pouvez utiliser des variables sur n’importe quel champ d’un enregistrement. 

Étape 3 - Configurer le nombre de threads

L’intérêt de JMeter est de pouvoir simuler plusieurs utilisateurs simultanément afin d’estimer la charge que peut tenir une application. Les utilisateurs sont simulés par des threads et chaque thread sera exécuté en simultané lors du lancement des scénarios.

Pour configurer le nombre de threads, cela se passe au niveau du Thread Group sur JMeter. 

À noter qu’un simple chiffre suffit pour indiquer le nombre de threads qui seront exécutés si l'on souhaite lancer nos scénarios depuis l’interface graphique. Ici nous avons spécifié la valeur suivante :

${__P(threads, 1}

Ceci est utile s’il on souhaite utiliser JMeter en ligne de commande. Ici, on précise que l’on récupère le nombre de threads passés en paramètre de la commande (dans le cas d’un lancement en ligne de commande), et, si ce paramètre n’existe pas (lancement depuis l’interface graphique par exemple), on spécifie une valeur par défaut (ici, 1).

Sur le même écran, on trouve un attribut « Ramp-up Period ». Cette valeur définit la durée, en seconde, pendant laquelle tous les threads seront démarrés afin que tous ne soient pas lancés en même temps.

Étape 4 - Configurer le nombre de loops

De la même manière, il est possible de configurer le nombre de boucles de vos scénarios, c’est-à-dire le nombre de fois que le scénario sera exécuté. Cette valeur peut également être récupérée depuis la commande shell. On peut aussi cocher la case « Infinite » pour que le nombre de boucle soit infini.

Étape 5 - Lancer les tirs de performance

Une fois le/les scénario(s) enregistré(s), on peut commencer les tirs de performance. Il y a 2 façons de le faire, via l’interface de JMeter ou en ligne de commande. L’interface est utile pour tester le bon fonctionnement du scénario car elle permet d’avoir plus de détail sur les appels effectués et de modifier les paramètres plus facilement. Lorsque tout est ok, il est intéressant de passer par les lignes de commandes, plus simple à lancer et qui permettent de générer un rapport CSV des tirs de performances effectués.

Via l’interface

Pour lancer les tirs de performance depuis l’interface, il suffit d’appuyer sur le bouton Run (flèche verte). 

L’ensemble des appels effectués avec leur détail apparaît dans View Results Tree et il est possible de stocker ses informations dans un fichier XML en le spécifiant dans le champ Filename (par défaut ces enregistrements ne sont pas sauvegardés et seront perdus si vous fermez JMeter). 

En ligne de commande

Pour lancer les tirs de performances en ligne de commande, on peut utiliser la commande suivante :

jmeter -f -n -t FICHIER_CONFIG_JMETER.jmx -l result .csv -Jthreads=50 -Jloop=10

Cette commande prend plusieurs paramètres :

• -f : permet d’écrire par-dessus le fichier CSV de destination si celui-ci existe déjà
• -n : indique que l’on lance JMeter sans interface
• -t : permet de spécifier le fichier de configuration utilisé
• -l : permet de spécifier le fichier csv dans lequel seront généré les résultats
• -Jthreads : permet indiquer le nombre de threads utilisés pour ce scénario
• -Jloop : permet d’indiquer le nombre de fois que sera lancé ce scénario

Le CSV généré comprend l’ensemble des appels effectués avec le code de réponse obtenu et le temps passé avant de l’obtenir.

Et voilà ! Vous êtes maintenant prêts à faire vos tests de performance !

Si vous souhaitez en discuter pour votre projet, dans le cadre d’un audit de performance par exemple, n’hésitez pas à nous contacter !