16. Meilleures pratiques ¶
16.1 Toujours utiliser 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 composants. Vous devez absolument éviter d'utiliser des versions antérieures à 3 versions avant la dernière.
16.2 Utiliser le bon nombre de threads ¶
Vos capacités matérielles ainsi que la conception du plan de test auront un impact sur le nombre de threads 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 threads, vous serez confronté au problème "d'omission coordonnée" qui peut 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 nœud 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 thread jusqu'à ce que le thread commence à échantillonner, c'est-à-dire après tout retard de groupe de threads et le temps de montée en puissance du thread lui-même. Cela permet un très grand nombre total de threads, à condition qu'il n'y en ait pas trop qui soient actifs simultanément.
16.3 Où placer le gestionnaire de cookies ¶
Voir Création d'un test Web pour plus d'informations.
16.4 Où placer le gestionnaire d'autorisations ¶
Voir Création d'un test Web avancé pour plus d'informations.
16.5 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 HTTP Request ). 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 "Modèle d'exclusion". 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 « serveur » 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} ".
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.
16.6 Variables utilisateur ¶
Certains plans de test doivent utiliser des valeurs différentes pour différents utilisateurs/threads. Par exemple, vous pouvez tester une séquence qui nécessite une connexion unique pour chaque utilisateur. Ceci est facile à réaliser avec les installations fournies par JMeter.
Par exemple:
- Créez un fichier texte contenant les noms d'utilisateur et les mots de passe, séparés par des virgules. Mettez ceci dans le même répertoire que votre plan de test.
- Ajoutez un élément de configuration CSV DataSet au plan de test. Nommez les variables USER et PASS .
- Remplacez le nom de connexion par ${USER} et le mot de passe par ${PASS} sur les échantillonneurs appropriés
L'élément CSV Data Set lira une nouvelle ligne pour chaque thread.
16.7 Réduction des besoins en ressources ¶
Quelques suggestions pour réduire l'utilisation des ressources.
- Utiliser le mode CLI : jmeter -n -t test.jmx -l test.jtl
- Utilisez le moins d'auditeurs possible ; si vous utilisez le drapeau -l comme ci-dessus, ils peuvent tous être supprimés ou désactivés.
- N'utilisez pas les écouteurs "View Results Tree" ou "View Results in Table" pendant le test de charge, utilisez-les uniquement pendant la phase de script pour déboguer vos scripts.
- Plutôt que d'utiliser de nombreux échantillonneurs similaires, utilisez le même échantillonneur dans une boucle et utilisez des variables (ensemble de données CSV) pour faire varier l'échantillon. [Le contrôleur d'inclusion n'aide pas ici, car il ajoute tous les éléments de test du fichier au plan de test.]
- Ne pas utiliser le mode fonctionnel
- Utiliser la sortie CSV plutôt que XML
- Enregistrez uniquement les données dont vous avez besoin
- Utilisez le moins d'assertions possible
- Utiliser le langage de script le plus performant (voir section JSR223)
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 qui peut être lu avec CSV Dataset. Cela évite de gaspiller des ressources lors de l'exécution.
16.8 Serveur BeanShell ¶
L'interpréteur BeanShell a une fonctionnalité très utile - il peut agir comme un serveur, accessible par telnet ou http.
Si vous souhaitez utiliser le serveur, définissez ce qui suit 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'impression de JMeter et des propriétés système. Voici ce que vous devriez voir dans la console JMeter :
Script de démarrage en cours d'exécution Script de démarrage terminé Httpd a démarré sur le port : 9000 Session démarrée sur le port : 9001
Il existe un exemple de script ( extras/remote.bsh ) que vous pouvez utiliser pour tester le serveur. [Jetez-y un œil pour voir comment cela fonctionne.]
Lorsque vous le démarrez dans le répertoire bin de JMeter (ajustez les chemins si nécessaire s'il s'exécute ailleurs), la sortie devrait ressembler à :
$ java -jar ../lib/bshclient.jar localhost 9000 ../extras/remote.bsh Connexion au serveur BSH sur localhost : 9000 Lecture des réponses du serveur… BeanShell 2.0b5 - par Pat Niemeyer (pat@pat.net) bsh % remote.bsh démarrage user.home = C:\Documents and Settings\Utilisateur user.dir = D:\eclipseworkspaces\main\JMeter_trunk\bin Définition de la propriété 'EXAMPLE' sur '0'. Définition de la propriété 'EXAMPLE' sur '1'. Définition de la propriété 'EXAMPLE' sur '2'. Définition de la propriété 'EXAMPLE' sur '3'. Définition de la propriété 'EXAMPLE' sur '4'. Définition de la propriété 'EXAMPLE' sur '5'. Définition de la propriété 'EXAMPLE' sur '6'. Définition de la propriété 'EXAMPLE' sur '7'. Définition de la propriété 'EXAMPLE' sur '8'. Définition de la propriété 'EXAMPLE' sur '9'. EXEMPLE = 9 remote.bsh terminé bsh % … déconnecté du serveur.
À 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 de débit constant qui est défini en termes de propriété, par exemple ${__P(throughput)} . Les commandes BeanShell suivantes peuvent être utilisées pour modifier le test :
printprop("débit");
curr = Integer.decode(args[0]); // Valeur de départ
inc = Integer.decode(args[1]); // Incrémenter
end = Integer.decode(args[2]); // Valeur finale
secondes = Integer.decode(args[3]); // Attendre entre les changements
tandis que(courant <= fin) {
setprop("débit",curr.toString()); // Doit être une chaîne ici
Thread.sleep(secs*1000);
curr += inc ;
}
printprop("débit");
Le script peut être stocké 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 débit.bsh 70 5 100 60
16.9 Scripts BeanShell ¶
16.9.1 Présentation ¶
Chaque élément de test BeanShell possède sa propre copie de l'interpréteur (pour chaque thread). Si l'élément de test est appelé à plusieurs reprises, par exemple dans une boucle, alors 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[;autres jars si nécessaire] bsh.Interpreter file.bsh [paramètres]ou
$ java -cp bsh-xxx.jar bsh.Interprète
bsh% source("fichier.bsh");
bsh% exit(); // ou utilisez la clé EOF (par exemple ^Z ou ^D)
16.9.2 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","Réussi");
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() qui peuvent être utilisées pour des objets arbitraires. Les variables JMeter sont locales à un thread, 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 threads, les propriétés JMeter peuvent être utilisées :
importer org.apache.jmeter.util.JMeterUtils ;
Valeur de chaîne = JMeterUtils.getPropDefault("name","");
JMeterUtils.setProperty("nom", "valeur");
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 :
monObj = 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.
16.10 Développer des fonctions de script dans Groovy ou Jexl3 etc. ¶
Il est assez difficile d'écrire et de tester des scripts en tant que fonctions. Cependant, JMeter dispose des échantillonneurs JSR223 qui peuvent être utilisés à la place avec n'importe quel langage le prenant en charge. Nous vous conseillons 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 stocké 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.
16.11 Paramétrage des tests ¶
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 threads 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 threads 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é " loops ", 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 …Si de nombreuses propriétés doivent être modifiées ensemble, une façon d'y parvenir consiste à 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 .
16.12 É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.
vars.get("varName")
Vous pouvez également les transmettre en tant que paramètres au script et les utiliser de cette façon.
16.13 Partage de variables entre threads et groupes de threads ¶
Les variables sont locales à un thread ; une variable définie dans un thread ne peut pas être lue dans un autre. C'est par conception. Pour les variables qui peuvent ê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 :
- Stockez la variable en tant que propriété - les propriétés sont globales à l'instance JMeter
- Ecrire des variables dans un fichier et les relire.
- Utilisez l' espace de noms bsh.shared - voir ci- dessus
- Écrivez vos propres classes Java
16.14 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é de 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".
16.15 É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 composants ) 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à.