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

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.

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

Après enregistrement, on obtient le script suivant :

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.

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.

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.

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

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

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

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.

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

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

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 :

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 :

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 :

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 :

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

#--------------------------------------------------------------------------- 
# 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

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

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.

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