Section courante

A propos

Section administrative du site

Les meilleures pratiques

Utilisez toujours la dernière version de JMeter

Les performances de JMeter sont constamment améliorées, les utilisateurs sont donc fortement encouragés à utiliser la version la plus récente. Assurez-vous de toujours lire la liste des modifications pour être au courant des nouvelles améliorations et des nouveaux composantes. Vous devez absolument éviter d'utiliser des versions antérieures à 3 versions avant la dernière.

Utilisez le bon nombre de processus léger

Vos capacités matérielles ainsi que la conception du plan de test auront un impact sur le nombre de processus léger que vous pouvez exécuter efficacement avec JMeter. Le nombre dépendra également de la vitesse de votre serveur (un serveur plus rapide rend JMeter plus efficace car il renvoie une réponse plus rapidement). Comme avec tout outil de test de charge, si vous ne dimensionnez pas correctement le nombre de processus léger, vous serez confronté au problème "d'omission coordonnée" pouvant vous donner des résultats erronés ou inexacts. Si vous avez besoin de tests de charge à grande échelle, envisagez d'exécuter plusieurs instances CLI JMeter sur plusieurs machines en mode distribué (ou non). Lors de l'utilisation du mode distribué, le fichier de résultats est combiné sur le noeud de contrôleur. Si vous utilisez plusieurs instances autonomes, les exemples de fichiers de résultats peuvent être combinés pour une analyse ultérieure. Pour tester les performances de JMeter sur une plate-forme donnée, l'échantillonneur JavaTest peut être utilisé. Il ne nécessite aucun accès au réseau et peut donc donner une idée du débit maximal réalisable.

JMeter a une option pour retarder la création de processus léger jusqu'à ce que le processus léger commence à échantillonner, c'est-à-dire après tout retard de groupe de processus léger et le temps de montée en puissance du processus léger lui-même. Cela permet un très grand nombre total de processus léger, à condition qu'il n'y en ait pas trop qui soient actifs simultanément.

Où placer le gestionnaire de cookies

Voir Création d'un test Web pour plus d'informations.

Où placer le gestionnaire d'autorisations

Voir Création d'un test Web avancé pour plus d'informations.

Utilisation de l'enregistreur de script de test HTTP(S)

Reportez-vous à HTTP(S) Test Script Recorder pour plus de détails sur la configuration de l'enregistreur. La chose la plus importante à faire est de filtrer toutes les requêtes qui ne vous intéressent pas. Par exemple, il est inutile d'enregistrer les requêtes d'images (JMeter peut être chargé de télécharger toutes les images d'une page - voir Requête HTTP). Ceux-ci ne feront qu'encombrer votre plan de test. Très probablement, tous vos fichiers partagent une extension, telle que .jsp, .asp, .php, .html ou similaire. Ceux-ci doivent être "inclus" en saisissant ".*\.jsp" comme "Include Pattern".

Alternativement, vous pouvez exclure des images en saisissant ".*\.gif" comme "Exclude Pattern". Selon votre application, cela peut ou non être une meilleure façon de procéder. Vous devrez peut-être également exclure des feuilles de style, des fichiers JavaScript et d'autres fichiers inclus. Testez vos paramètres pour vérifier que vous enregistrez ce que vous voulez, puis effacez et recommencez.

L'enregistreur de script de test HTTP(S) s'attend à trouver un élément ThreadGroup avec un contrôleur d'enregistrement sous celui-ci où il enregistrera les requêtes HTTP. Cela regroupe commodément tous vos échantillons sous un seul contrôleur, qui peut recevoir un nom qui décrit le cas de test.

Maintenant, suivez les étapes d'un scénario de test. Si vous n'avez pas de cas de test prédéfinis, utilisez JMeter pour enregistrer vos actions afin de définir vos cas de test. Une fois que vous avez terminé une série d'étapes définies, enregistrez l'intégralité du cas de test dans un fichier nommé de manière appropriée. Ensuite, nettoyez et démarrez un nouveau cas de test. En procédant ainsi, vous pouvez rapidement enregistrer un grand nombre de "brouillons" de cas de test.

L'une des fonctionnalités les plus utiles de l'enregistreur de script de test HTTP(S) est que vous pouvez extraire certains éléments communs des échantillons enregistrés. En définissant certaines variables définies par l'utilisateur au niveau du plan de test ou dans les éléments Variables définies par l'utilisateur, vous pouvez demander à JMeter de remplacer automatiquement les valeurs dans vos échantillons enregistrés. Par exemple, si vous testez une application sur le serveur "xxx.example.com", vous pouvez définir une variable appelée "server" avec la valeur de "xxx.example.com", et n'importe où cette valeur se trouve dans votre fichier enregistré. Les échantillons seront remplacés par "${server}".

Veuillez noter que la correspondance est sensible à la casse.

Si JMeter n'enregistre aucun échantillon, vérifiez que le navigateur utilise bien le proxy. Si le navigateur fonctionne correctement même si JMeter n'est pas en cours d'exécution, le navigateur ne peut pas utiliser le proxy. Certains navigateurs ignorent les paramètres de proxy pour localhost ou 127.0.0.1 ; essayez d'utiliser le nom d'hôte local ou l'IP à la place.

L'erreur "unknown_ca" signifie probablement que vous essayez d'enregistrer HTTPS et que le navigateur n'a pas accepté le certificat du serveur proxy JMeter.

Variables utilisateur

Certains plans de test doivent utiliser des valeurs différentes pour différents utilisateurs/processus léger. Par exemple, vous pouvez tester une séquence nécessitant une connexion unique pour chaque utilisateur. Ceci est facile à réaliser avec les installations fournies par JMeter.

Par exemple :

L'élément CSV Data Set lira une nouvelle ligne pour chaque processus léger.

Réduire les besoins en ressources

Quelques suggestions pour réduire l'utilisation des ressources.

Si votre test nécessite de grandes quantités de données - en particulier s'il doit être randomisé - créez les données de test dans un fichier pouvant être lu avec CSV Dataset. Cela évite de gaspiller des ressources lors de l'exécution.

Serveur BeanShell

L'interpréteur BeanShell a une fonctionnalité très utile - il peut agir comme un serveur, accessible par telnet ou http.

Il n'y a pas de sécurité. Toute personne pouvant se connecter au port peut émettre n'importe quelle commande BeanShell. Ceux-ci peuvent fournir un accès illimité à l'application JMeter et à l'hôte. N'activez le serveur que si les ports sont protégés contre l'accès, par exemple par un pare-feu.

Si vous souhaitez utiliser le serveur, définissez les éléments suivants dans jmeter.properties :

beanshell.server.port=9000
beanshell.server.file=../extras/startup.bsh

Dans l'exemple ci-dessus, le serveur sera démarré et écoutera sur les ports 9000 et 9001. Le port 9000 sera utilisé pour l'accès http. Le port 9001 sera utilisé pour l'accès telnet. Le fichier startup.bsh sera traité par le serveur et peut être utilisé pour définir diverses fonctions et configurer des variables. Le fichier de démarrage définit les méthodes de définition et d'affichage de JMeter et des propriétés système. Voici ce que vous devriez voir dans la console JMeter :

Startup script running
Startup script completed
Httpd started on port: 9000
Session started on port: 9001

Il existe un exemple de script (extras/remote.bsh) que vous pouvez utiliser pour tester le serveur. Lorsque vous le démarrez dans le répertoire bin de JMeter (ajustez les chemins si nécessaire s'il s'exécute d'ailleurs), la sortie devrait ressembler à :

$ java -jar ../lib/bshclient.jar localhost 9000 ../extras/remote.bsh
Connecting to BSH server on localhost:9000
Reading responses from server ...
BeanShell 2.0b5 - by Pat Niemeyer (pat@pat.net)
bsh % remote.bsh starting
user.home = C:\Documents and Settings\User
user.dir = D:\eclipseworkspaces\main\JMeter_trunk\bin
Setting property 'EXAMPLE' to '0'.
Setting property 'EXAMPLE' to '1'.
Setting property 'EXAMPLE' to '2'.
Setting property 'EXAMPLE' to '3'.
Setting property 'EXAMPLE' to '4'.
Setting property 'EXAMPLE' to '5'.
Setting property 'EXAMPLE' to '6'.
Setting property 'EXAMPLE' to '7'.
Setting property 'EXAMPLE' to '8'.
Setting property 'EXAMPLE' to '9'.
EXAMPLE = 9
remote.bsh ended
bsh % ... disconnected from server.

À titre d'exemple pratique, supposons que vous ayez un test JMeter de longue durée exécuté en mode CLI et que vous souhaitiez faire varier le débit à différents moments du test. Le plan de test comprend un temporisateur à débit constant qui est défini en termes de propriété, par ex. ${__P(débit)}. Les commandes BeanShell suivantes peuvent être utilisées pour modifier le test :

printprop("throughput");
curr = Integer.decode(args[0]); // Valeur de début
inc = Integer.decode(args[1]); // Incrément
end = Integer.decode(args[2]); // Valeur finale
secs = Integer.decode(args[3]); // Attendre entre les changements
while(curr <= end) {
   setprop("throughput",curr.toString()); // Doit être une chaîne de caractères ici
   Thread.sleep(secs*1000);
   curr += inc;
}
printprop("throughput");

Le script peut être entreposé dans un fichier (throughput.bsh, par exemple) et envoyé au serveur à l'aide de bshclient.jar. Par exemple :

java -jar ../lib/bshclient.jar localhost 9000 throughput.bsh 70 5 100 60

Script BeanShell

Depuis JMeter 3.1, il est conseillé de passer de BeanShell à JSR223 Test Elements, et de passer de la fonction __Beanshell à la fonction __groovy.

Aperçu

Chaque élément de test BeanShell possède sa propre copie de l'interpréteur (pour chaque processus léger). Si l'élément de test est appelé à plusieurs reprises, par exemple dans une boucle, l'interpréteur est conservé entre les invocations à moins que l'option "Réinitialiser bsh.Interpreter avant chaque appel" ne soit sélectionnée.

Certains tests de longue durée peuvent amener l'interpréteur à utiliser beaucoup de mémoire ; si tel est le cas, essayez d'utiliser l'option de réinitialisation.

Vous pouvez tester les scripts BeanShell en dehors de JMeter en utilisant l'interpréteur de ligne de commande :

$ java -cp bsh-xxx.jar[;other jars as needed] bsh.Interpreter file.bsh [parameters]

ou :

$ java -cp bsh-xxx.jar bsh.Interpreter
bsh% source("file.bsh");
bsh% exit(); // ou utilisez la touche EOF (par exemple ^Z ou ^D)

Partage de variables

Les variables peuvent être définies dans les scripts de démarrage (initialisation). Ceux-ci seront conservés lors des invocations de l'élément de test, à moins que l'option de réinitialisation ne soit utilisée.

Les scripts peuvent également accéder aux variables JMeter en utilisant les méthodes get() et put() de la variable "vars", par exemple :

vars.get("HOST");
vars.put("MSG","Successful");

Les méthodes get() et put() ne prennent en charge que les variables avec des valeurs String, mais il existe également des méthodes getObject() et putObject() pouvant être utilisées pour des objets arbitraires. Les variables JMeter sont locales à un processus léger, mais peuvent être utilisées par tous les éléments de test (pas seulement Beanshell).

Si vous avez besoin de partager des variables entre les processus léger, les propriétés JMeter peuvent être utilisées :

import org.apache.jmeter.util.JMeterUtils;
String value = JMeterUtils.getPropDefault("name","");
JMeterUtils.setProperty("name", "value");

Les exemples de fichiers .bshrc contiennent des exemples de définitions des méthodes getprop() et setprop().

Une autre méthode possible de partage de variables consiste à utiliser l'espace de noms partagé "bsh.shared". Par exemple :

if (bsh.shared.myObj == void){
   // pas encore défini, alors créez-le :
   myObj = new AnyObject();
}
bsh.shared.myObj.process();

Plutôt que de créer l'objet dans l'élément de test, il peut être créé dans le fichier de démarrage défini par la propriété JMeter "beanshell.init.file". Celui-ci n'est traité qu'une seule fois.

Développer des fonctions de script dans Groovy ou Jexl3 ....

Il est assez difficile d'écrire et de tester des scripts en tant que fonctions. Cependant, JMeter dispose des échantillonneurs JSR223 pouvant être utilisés à la place avec n'importe quel langage le prenant en charge. Il est conseillé d'utiliser Apache Groovy ou tout autre langage prenant en charge l'interface compilable de JSR223.

Créez un plan de test simple contenant l'échantillonneur JSR223 et l'écouteur Tree View. Codez le script dans le volet de script de l'échantillonneur et testez-le en exécutant le test. S'il y a des erreurs, celles-ci apparaîtront dans l'arborescence et le fichier jmeter.log. De plus, le résultat de l'exécution du script apparaîtra comme réponse.

Une fois que le script fonctionne correctement, il peut être entreposé en tant que variable sur le plan de test. La variable de script peut ensuite être utilisée pour créer l'appel de fonction. Par exemple, supposons qu'un script Groovy soit stocké dans la variable RANDOM_NAME. L'appel de fonction peut alors être codé comme ${__groovy(${RANDOM_NAME})}. Il n'est pas nécessaire d'échapper des virgules dans le script, car l'appel de fonction est analysé avant que la valeur de la variable ne soit interpolée.

Test de paramétrage

Il est souvent utile de pouvoir réexécuter le même test avec des paramètres différents. Par exemple, changer le nombre de processus légers ou de boucles, ou changer un nom d'hôte.

Une façon de procéder consiste à définir un ensemble de variables sur le plan de test, puis à utiliser ces variables dans les éléments de test. Par exemple, on pourrait définir la variable LOOPS=10 et s'y référer dans le groupe de processus léger en tant que ${LOOPS}. Pour exécuter le test avec 20 boucles, modifiez simplement la valeur de la variable LOOPS sur le plan de test.

Cela devient rapidement fastidieux si vous souhaitez exécuter de nombreux tests en mode CLI. Une solution consiste à définir la variable Plan de test en termes de propriété, par exemple LOOPS=${__P(loops,10)}. Cela utilise la valeur de la propriété "boucles", par défaut à 10 si la propriété n'est pas trouvée. La propriété "loops" peut alors être définie sur la ligne de commande JMeter :

jmeter ... -Jloops=12 ...

S'il y a beaucoup de propriétés devant être modifiées ensemble, une façon d'y parvenir est d'utiliser un ensemble de fichiers de propriétés. Le fichier de propriétés approprié peut être transmis à JMeter à l'aide de l'option de ligne de commande -q.

Éléments JSR223

Pour les tests de charge intensifs, le langage de script recommandé est celui dont ScriptingEngine implémente l'interface Compilable. Le moteur de script Groovy implémente Compilable. Cependant, ni Beanshell ni Javascript ne le font à la date de sortie de JMeter 3.1, il est donc recommandé de les éviter pour les tests de charge intensifs.

Remarque : Beanshell implémente l'interface Compilable mais elle n'a pas été codée - la méthode lève simplement une exception. JMeter a une solution explicite pour ce bogue.

Lors de l'utilisation d'éléments JSR 223, il est conseillé de vérifier la propriété Mettre en cache le script compilé si disponible pour s'assurer que la compilation du script est mise en cache si le langage sous-jacent le prend en charge. Dans ce cas, assurez-vous que le script n'utilise aucune variable utilisant ${varName} car la mise en cache ne prendrait que la première valeur de ${varName}. Utilisez plutôt :

vars.get("varName")

Vous pouvez également les transmettre en tant que paramètres au script et les utiliser de cette façon.

Partage de variables entre processus léger et groupes de processus léger

Les variables sont locales à un processus léger ; une variable définie dans un processus léger ne peut pas être lue dans un autre. C'est par conception. Pour les variables pouvant être déterminées avant le début d'un test, voir Paramétrage des tests (ci-dessus). Si la valeur n'est connue qu'au démarrage du test, plusieurs options s'offrent à vous :

Gestion des propriétés

Lorsque vous devez modifier les propriétés jmeter, assurez-vous de ne pas modifier le fichier jmeter.properties, copiez plutôt la propriété depuis jmeter.properties et modifiez sa valeur dans le fichier user.properties.

Cela facilitera votre migration vers la prochaine version de JMeter.

Notez que dans la documentation jmeter.properties est fréquemment mentionné mais cela doit être compris comme «Copier de jmeter.properties vers user.properties la propriété que vous souhaitez modifier et faites-le dans ce dernier fichier».

Le fichier user.properties remplace les propriétés définies dans jmeter.properties.

Éléments obsolètes

Il est conseillé de ne pas utiliser d'éléments obsolètes (marqués comme tels dans la liste des modifications et dans la référence des composantes) et de migrer vers de nouveaux éléments conseillés s'ils sont disponibles ou une nouvelle façon de faire la même chose.

Les éléments obsolètes sont supprimés du menu dans la version N mais peuvent être activés pour la migration en modifiant la propriété not_in_menu dans le fichier user.properties et en supprimant le nom de classe complet de l'élément à partir de là.

Veuillez noter que les éléments obsolètes de la version N seront supprimés définitivement dans la version N+1, alors assurez-vous de cesser de les utiliser dès que possible.



Dernière mise à jour : Vendredi, le 18 août 2023