Les premiers pas
Lorsque vous utilisez JMeter, vous suivrez généralement ce processus :
Construction du plan de test
Pour ce faire, vous exécuterez JMeter en mode GUI.
Ensuite, vous pouvez soit choisir d'enregistrer l'application depuis un navigateur, soit une application native. Vous pouvez utiliser pour cela le menu File → Templates... → Recording.
Notez que vous pouvez également créer votre plan manuellement. Assurez-vous de lire cette documentation pour comprendre les principaux concepts. Vous pourrez également le déboguer en utilisant l'une de ces options :
- Run → Start no pauses
- Run → Start
- Validate dansn Thread Group
et afficher les moteurs de rendu (View Results Tree) ou les testeurs de l'arborescence des résultats (CSS/JQUERY, JSON, Regexp, XPath). Assurez-vous de suivre les meilleures pratiques lors de la création de votre plan de test.
Test de charge en cours
Une fois votre plan de test prêt, vous pouvez commencer votre test de charge. La première étape consiste à configurer les injecteurs exécutant JMeter, ceci comme pour tout autre outil de test de charge comprend :
- Dimensionnement correct de la machine en termes de microprocesseur, de mémoire et de réseau
- Réglage du système d'exploitation
- Configuration de Java : assurez-vous d'installer la dernière version de Java prise en charge par JMeter.
- Augmentez la taille du tas Java. Par défaut, JMeter s'exécute avec un tas de 1 Go, cela peut ne pas être suffisant pour votre test et dépend de votre plan de test et du nombre de processus léger que vous souhaitez exécuter.
Une fois que tout est prêt, vous utiliserez le mode CLI (mode ligne de commande précédemment appelé mode non graphique) pour l'exécuter pour le test de charge.
N'exécutez pas de test de charge en utilisant le mode graphique !
En utilisant le mode CLI, vous pouvez générer un fichier CSV (ou XML) contenant les résultats et demander à JMeter de générer un rapport HTML à la fin du test de charge. JMeter fournira par défaut un résumé du test de charge pendant son exécution. Vous pouvez également avoir des résultats en temps réel pendant votre test en utilisant Backend Listener.
Analyse des tests de charge
Une fois votre test de charge terminé, vous pouvez utiliser le rapport HTML pour analyser votre test de charge.
Commençons
Le moyen le plus simple de commencer à utiliser JMeter est de télécharger d'abord la dernière version de production et de l'installer. La version contient tous les fichiers dont vous avez besoin pour créer et exécuter la plupart des types de tests, par ex. Web (HTTP/HTTPS), FTP, JDBC, LDAP, Java, JUnit et plus encore.
Si vous souhaitez effectuer des tests JDBC, vous aurez bien sûr besoin du pilote JDBC approprié de votre fournisseur. JMeter n'est fourni avec aucun pilote JDBC.
JMeter inclut le jar de l'API JMS, mais n'inclut pas d'implémentation de client JMS. Si vous souhaitez exécuter des tests JMS, vous devrez télécharger les fichiers JAR appropriés à partir du fournisseur JMS.
Ensuite, démarrez JMeter et parcourez la section Building a Test Plan du Guide de l'utilisateur pour vous familiariser avec les bases de JMeter (par exemple, ajouter et supprimer des éléments).
Enfin, parcourez la section appropriée sur la façon de créer un type spécifique de plan de test. Par exemple, si vous souhaitez tester une application Web, consultez la section Building a Web Test Plan. Les autres sections spécifiques du plan de test sont :
- Plan de test Web avancé
- JDBC
- FTP
- Point à point JMS
- Rubrique JMS
- LDAP
- LDAP étendu
- Webservices (SOAP)
- Construire un plan de test par programmation
Une fois que vous êtes à l'aise avec la création et l'exécution de plans de test JMeter, vous pouvez examiner les différents éléments de configuration (minuteries, écouteurs, assertions et autres) qui vous donnent plus de contrôle sur vos plans de test.
Prérequis
JMeter exige que votre environnement informatique réponde à certaines exigences minimales.
Version Java
JMeter est compatible avec Java 8 ou supérieur. Nous vous conseillons vivement d'installer la dernière version mineure de votre version majeure pour des raisons de sécurité et de performances.
Étant donné que JMeter utilise uniquement des API Java standard, veuillez ne pas envoyer de rapport de bogue si votre JRE ne parvient pas à exécuter JMeter en raison de problèmes d'implémentation de JRE.
Bien que vous puissiez utiliser un JRE, il est préférable d'installer un JDK car pour l'enregistrement de HTTPS, JMeter a besoin de l'utilitaire keytool de JDK.
Systèmes d'exploitation
JMeter est une application 100% Java et devrait fonctionner correctement sur tout système disposant d'une implémentation Java conforme.
Facultatif
Si vous envisagez de développer JMeter, vous aurez besoin d'un ou plusieurs paquets facultatifs répertoriés ci-dessous.
Compilateur Java
Si vous souhaitez créer la source JMeter ou développer des plugiciels JMeter, vous aurez besoin d'un JDK 8 ou supérieur entièrement compatible.
Analyseur XML SAX
JMeter est livré avec l'analyseur XML Xerces d'Apache. Vous avez la possibilité de dire à JMeter d'utiliser un analyseur XML différent. Pour ce faire, incluez les classes de l'analyseur tiers dans le chemin de classe de JMeter et mettez à jour le fichier jmeter.properties avec le nom de classe complet de l'implémentation de l'analyseur.
Assistance par courriel
JMeter dispose de fonctionnalités de messagerie étendues. Il peut envoyer des courriels en fonction des résultats des tests et dispose d'un échantillonneur POP3/IMAP. Il dispose également d'un échantillons.
Cryptage SSL
Pour tester un serveur Web utilisant le cryptage SSL (HTTPS), JMeter nécessite qu'une implémentation de SSL soit fournie, comme c'est le cas avec Sun Java 1.4 et supérieur. Si votre version de Java n'inclut pas le support SSL, il est alors possible d'ajouter une implémentation externe. Incluez les paquets de chiffrement nécessaires dans le chemin de classe de JMeter. Mettez également à jour system.properties pour enregistrer le fournisseur SSL.
JMeter HTTP utilise par défaut le niveau de protocole TLS. Cela peut être modifié en modifiant la propriété JMeter https.default.protocol dans jmeter.properties ou user.properties.
Les échantillonneurs HTTP JMeter sont configurés pour accepter tous les certificats, qu'ils soient fiables ou non, quelles que soient les périodes de validité,... Ceci afin de permettre une flexibilité maximale dans le test des serveurs.
Si le serveur requiert un certificat client, celui-ci peut être fourni.
Il y a aussi le gestionnaire SSL, pour un meilleur contrôle des certificats.
Le serveur proxy JMeter (voir ci-dessous) prend en charge l'enregistrement HTTPS (SSL).
L'échantillonneur SMTP peut éventuellement utiliser un magasin de confiance local ou approuver tous les certificats.
Pilote JDBC
Vous devrez ajouter le pilote JDBC de votre fournisseur de base de données au chemin de classe si vous souhaitez effectuer des tests JDBC. Assurez-vous que le fichier est un fichier jar, pas un zip.
Client JMS
JMeter inclut désormais l'API JMS d'Apache Geronimo, il vous suffit donc d'ajouter le ou les fichiers JMS d'implémentation du client JMS appropriés du fournisseur JMS.
Bibliothèques pour ActiveMQ JMS
Vous devrez ajouter le jar activemq-all-X.X.X.jar à votre chemin de classe, par exemple en l'entreposant dans le répertoire «lib/».
Installation
Nous recommandons à la plupart des utilisateurs d'exécuter la dernière version.
Pour installer une version de version, décompressez simplement le fichier zip/tar dans le répertoire où vous souhaitez installer JMeter. Pourvu que vous ayez un JRE/JDK correctement installé et que la variable d'environnement JAVA_HOME soit définie, vous n'avez plus rien à faire.
Il peut y avoir des problèmes (en particulier avec le mode client-serveur) si le chemin du répertoire contient des espaces.
La structure du répertoire d'installation devrait ressembler à ceci (où X.Y est le numéro de version) :
|
apache-jmeter-X.Y apache-jmeter-X.Y/bin apache-jmeter-X.Y/docs apache-jmeter-X.Y/extras apache-jmeter-X.Y/lib/ apache-jmeter-X.Y/lib/ext apache-jmeter-X.Y/lib/junit apache-jmeter-X.Y/licenses apache-jmeter-X.Y/printable_docs |
Vous pouvez renommer le répertoire parent (c'est-à-dire apache-jmeter-X.Y) si vous le souhaitez, mais ne modifiez aucun des noms de sous-répertoires.
Exécution de JMeter
Pour exécuter JMeter, exécutez le fichier jmeter.bat (pour Windows) ou jmeter (pour Unix). Ces fichiers se trouvent dans le répertoire bin. Après un court instant, l'interface graphique de JMeter devrait apparaître.
Le mode GUI ne doit être utilisé que pour créer le script de test, le mode CLI (NON GUI) doit être utilisé pour les tests de charge.
Il y a quelques scripts supplémentaires dans le répertoire bin pouvant vous être utiles. Fichiers de script Windows (les fichiers .CMD nécessitent Win2K ou version ultérieure) :
| Fichier | Description |
|---|---|
| jmeter.bat | Exécuter JMeter (en mode graphique par défaut) |
| jmeterw.cmd | Exécuter JMeter sans la console d'interpréteur de commande Windows (en mode graphique par défaut) |
| jmeter-n.cmd | Déposez un fichier JMX dessus pour exécuter un test en mode CLI |
| jmeter-n-r.cmd | Déposez un fichier JMX dessus pour exécuter un test en mode CLI à distance. |
| jmeter-t.cmd | Déposez un fichier JMX dessus pour le charger en mode graphique. |
| jmeter-server.bat | Démarrer JMeter en mode serveur. |
| mirror-server.cmd | Exécute le serveur miroir JMeter en mode CLI. |
| shutdown.cmd | Exécutez le client Shutdown pour arrêter correctement une instance en mode CLI |
| stoptest.cmd | Exécutez le client Shutdown pour arrêter brusquement une instance en mode CLI |
Le nom spécial LAST peut être utilisé avec jmeter-n.cmd, jmeter-t.cmd et jmeter-n-r.cmd et signifie le dernier plan de test ayant été exécuté de manière interactive.
Il existe quelques variables d'environnement pouvant être utilisées pour personnaliser les paramètres JVM pour JMeter. Un moyen simple de les définir consiste à créer un fichier nommé setenv.bat dans le répertoire bin. Un tel fichier pourrait ressembler à :
|
rem C'est le contenu de bin\setenv.bat, rem il sera appelé par bin\jmeter.bat set JVM_ARGS=-Xms1024m -Xmx1024m -Dpropname=value |
Le JVM_ARGS peut être utilisé pour remplacer les paramètres JVM dans le script jmeter.bat et sera défini lors du démarrage de JMeter, par exemple :
| jmeter -t test.jmx ... |
Les variables d'environnement suivantes peuvent être définies :
| Variable d'environnement | Description |
|---|---|
| DDRAW | Options JVM pour influencer l'utilisation du tirage direct, par exemple : -Dsun.java2d.ddscale=true. La valeur par défaut est vide. |
| GC_ALGO | Options du ramasse-miettes JVM. La valeur par défaut est -XX :+UseG1GC -XX :MaxGCPauseMillis=250 -XX :G1ReservePercent=20. |
| HEAP | Paramètres de mémoire JVM utilisés lors du démarrage de JMeter. Par défaut -Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m. |
| JMETER_BIN | Répertoire bin de JMeter (doit se terminer par \). La valeur aura été devinée lors de l'appel de setenv.bat. |
| JMETER_COMPLETE_ARGS | Si set indique que JVM_ARGS et JMETER_OPTS doivent être utilisés uniquement. Toutes les autres options comme HEAP et GC_ALGO seront ignorées. La valeur par défaut est vide. |
| JMETER_HOME | Répertoire d'installation. Sera deviné à partir de l'emplacement de jmeter.bat. |
| JMETER_LANGUAGE | Options d'exécution Java pour spécifier la langue utilisée. Par défaut : -Duser.language="en" -Duser.region="EN" |
| JM_LAUNCH | Nom de l'exécutable java, comme java.exe (par défaut) ou javaw.exe. |
| JVM_ARGS | Options Java à utiliser lors du démarrage de JMeter. Ceux-ci seront ajoutés en dernier à la commande java. La valeur par défaut est vide. |
Fichiers de script Un*x; devrait fonctionner sur la plupart des systèmes Linux/Unix :
| Fichier de script | Description |
|---|---|
| jmeter | Exécute JMeter (en mode graphique par défaut). Définit certains paramètres JVM pouvant ne pas fonctionner pour toutes les JVM. |
| jmeter-server | Démarrer JMeter en mode serveur (appelle le script jmeter avec les paramètres appropriés). |
| jmeter.sh | Script JMeter très basique (vous devrez peut-être adapter les options JVM comme les paramètres de mémoire). |
| mirror-server.sh | Exécute le serveur miroir JMeter en mode CLI. |
| shutdown.sh | Exécutez le client Shutdown pour arrêter correctement une instance en mode CLI. |
| stoptest.sh | Exécutez le client Shutdown pour arrêter brusquement une instance en mode CLI |
Il peut être nécessaire de définir quelques variables d'environnement pour configurer la JVM utilisée par JMeter. Ces variables peuvent être définies directement dans l'interpréteur de commande en démarrant le script jmeter. Par exemple, la définition de la variable JVM_ARGS remplacera la plupart des paramètres prédéfinis, par exemple :
| JVM_ARGS="-Xms1024m -Xmx1024m" jmeter -t test.jmx [...] |
remplacera les paramètres HEAP dans le script.
Pour définir ces variables de manière permanente, vous pouvez les placer dans un fichier appelé setenv.sh dans le répertoire bin. Ce fichier sera sourcé lors de l'exécution de JMeter en appelant le script jmeter. Un exemple pour bin/setenv.sh pourrait ressembler à :
|
# C'est le fichier bin/setenv.sh, # il sera sourcé par bin/jmeter # Utiliser un tas plus grand, mais un métaspace plus petit, que la valeur par défaut export HEAP="-Xms1G -Xmx1G -XX:MaxMetaspaceSize=192m" # Essayez de deviner les paramètres régionaux du système d'exploitation. L'espace comme valeur est exprès ! export JMETER_LANGUAGE=" " |
Les variables d'environnement suivantes peuvent être définies :
| Variable d'environnement | Description |
|---|---|
| GC_ALGO | Options d'exécution Java pour spécifier l'algorithme de récupération de place JVM. La valeur par défaut est -XX :+UseG1GC -XX :MaxGCPauseMillis=250 -XX :G1ReservePercent=20 |
| HEAP | Options d'exécution Java pour la gestion de la mémoire utilisées au démarrage de JMeter. Par défaut -Xms1g -Xmx1g -X:MaxMetaspaceSize=256m. |
| JAVA_HOME | Doit pointer vers l'installation de votre kit de développement Java. Requis pour exécuter le avec le paramètre "debug". Sur certains systèmes d'exploitation, JMeter fera de son mieux pour deviner l'emplacement de la JVM. |
| JMETER_COMPLETE_ARGS | Si set indique que JVM_ARGS et JMETER_OPTS doivent être utilisés uniquement. Toutes les autres options comme HEAP et GC_ALGO seront ignorées. La valeur par défaut est vide. |
| JMETER_HOME | Peut pointer vers votre répertoire d'installation JMeter. S'il est vide, il sera défini par rapport au script jmeter. |
| JMETER_LANGUAGE | Options d'exécution Java pour spécifier la langue utilisée. Par défaut, -Duser.language=en -Duser.region=EN. |
| JMETER_OPTS | Options d'exécution Java utilisées au démarrage de JMeter. Des options spéciales pour les systèmes d'exploitation peuvent être ajoutées par JMeter. |
| JRE_HOME | Doit pointer vers votre installation Java Runtime. La valeur par défaut est JAVA_HOME si vide. Si JRE_HOME et JAVA_HOME sont tous deux vides, JMeter essaiera de deviner JAVA_HOME. Si JRE_HOME et JAVA_HOME sont tous deux définis, JAVA_HOME est utilisé. |
| JVM_ARGS | Options Java à utiliser lors du démarrage de JMeter. Ceux-ci seront ajoutés avant JMETER_OPTS et après les autres options JVM. La valeur par défaut est vide. |
Classpath de JMeter
JMeter trouve automatiquement les classes des jars dans les répertoires suivants :
| Nom | Description |
|---|---|
| JMETER_HOME/lib | Utilisé pour les jars d'utilitaires |
| JMETER_HOME/lib/ext | Utilisé pour les composantes et plugins JMeter |
Si vous avez développé de nouveaux composantes JMeter, vous devez les jar et copier le jar dans le répertoire lib/ext de JMeter. JMeter trouvera automatiquement les composantes JMeter dans tous les pots trouvés ici. N'utilisez pas lib/ext pour les jars utilitaires ou les jars de dépendance utilisés par les plugins ; il est uniquement destiné aux composants et plugins JMeter.
Si vous ne souhaitez pas placer les jars du plug-in JMeter dans le répertoire lib/ext, définissez la propriété search_paths dans jmeter.properties.
Les jars d'utilitaires et de dépendances (bibliothèques,...) peuvent être placés dans le répertoire lib.
Si vous ne voulez pas mettre de tels jars dans le répertoire lib, définissez la propriété user.classpath ou plugin_dependency_paths dans jmeter.properties. Voir ci-dessous pour une explication des différences.
Les autres jars (tels que JDBC, les implémentations JMS et toute autre bibliothèque de support requise par le code JMeter) doivent être placés dans le répertoire lib - et non dans le répertoire lib/ext, ou ajoutés à user.classpath.
JMeter ne trouvera que les fichiers .jar, pas .zip.
Vous pouvez également installer des fichiers Jar utilitaires dans $JAVA_HOME/jre/lib/ext, ou vous pouvez définir la propriété user.classpath dans jmeter.properties.
Notez que la définition de la variable d'environnement CLASSPATH n'aura aucun effet. En effet, JMeter est démarré avec "java -jar" et la commande java ignore silencieusement la variable CLASSPATH et les options -classpath/-cp lorsque -jar est utilisé.
Cela se produit avec tous les programmes Java, pas seulement JMeter.
Créer un plan de test à partir d'un gabarit
Vous avez la possibilité de créer un nouveau plan de test à partir d'un gabarit existant.
Pour cela, utilisez le menu File → Templates... ou l'icône Templates :
Une popup apparaît, vous pouvez alors choisir un gabarit parmi la liste :
Certains gabarits peuvent nécessiter la saisie de paramètres par l'utilisateur. Pour celles-ci, après un clic sur le bouton créer, une nouvelle fenêtre apparaîtra comme suit :
Lorsque vous avez terminé avec les paramètres, cliquez sur le bouton Validate et le gabarit sera créé.
Une documentation pour chaque gabarit explique ce qu'il faut faire une fois le plan de test créé à partir du gabarit.
Utiliser JMeter derrière un proxy
Si vous testez derrière un pare-feu/serveur proxy, vous devrez peut-être fournir à JMeter le nom d'hôte et le numéro de port du pare-feu/serveur proxy. Pour ce faire, exécutez le fichier jmeter[.bat] depuis une ligne de commande avec les paramètres suivants :
| Paramètres | Description |
|---|---|
| -E | Ce paramètre permet d'indiquer un schéma proxy à utiliser - facultatif - pour non-http. |
| -H | Ce paramètre permet d'indiquer un nom d'hôte ou adresse IP du serveur proxy. |
| -P | Ce paramètre permet d'indiquer un port du serveur proxy. |
| -N | Ce paramètre permet d'indiquer les hôtes non proxy. Par exemple : «*.apache.org|localhost». |
| -u | Ce paramètre permet d'indiquer le nom d'utilisateur pour l'authentification proxy - si nécessaire. |
| -a | Ce paramètre permet d'indiquer le mot de passe pour l'authentification proxy - si nécessaire. |
Exemple :
| jmeter -E https -H my.proxy.server -P 8000 -u username -a password -N localhost |
Vous pouvez également utiliser --proxyScheme, --proxyHost, --proxyPort, --username et --password comme noms de paramètres. Les paramètres fournis sur une ligne de commande peuvent être visibles par d'autres utilisateurs du système.
Si le schéma de proxy est fourni, alors JMeter définit les propriétés système suivantes :
- http.proxyScheme
Si l'hôte proxy et le port sont fournis, alors JMeter définit les propriétés système suivantes :
- http.proxyHost
- http.proxyPort
- https.proxyHost
- https.proxyPort
L'utilisateur et le mot de passe utilisés pour un proxy peuvent être donnés par les propriétés système http.proxyUser et http.proxyUser. Ils seront remplacés par les paramètres ou valeurs ci-dessus définis dans les échantillonneurs HTTP.
Si une liste d'hôtes non proxy est fournie, JMeter définit les propriétés système suivantes :
- http.nonProxyHosts
- https.nonProxyHosts
Ainsi, si vous ne souhaitez pas définir à la fois les proxies http et https, vous pouvez définir les propriétés pertinentes dans system.properties au lieu d'utiliser les paramètres de ligne de commande.
Les paramètres de proxy peuvent également être définis dans un plan de test, à l'aide de la configuration des valeurs par défaut de la requête HTTP ou des éléments de l'échantillonneur de requête HTTP.
JMeter possède également son propre serveur proxy intégré, l'enregistreur de script de test HTTP(S). Ceci n'est utilisé que pour enregistrer des sessions de navigateur HTTP ou HTTPS. Cela ne doit pas être confondu avec les paramètres de proxy décrits ci-dessus, étant utilisés lorsque JMeter effectue lui-même des requêtes HTTP ou HTTPS.
Mode CLI (le mode ligne de commande était appelé mode NON GUI)
Pour les tests de charge, vous devez exécuter JMeter dans ce mode (sans l'interface graphique) pour en obtenir les résultats optimaux. Pour ce faire, utilisez les options de commande suivantes :
| Options | Description |
|---|---|
| -n | Cela spécifie que JMeter doit s'exécuter en mode CLI |
| -t | Nom du fichier JMX contenant le plan de test. |
| -l | Nom du fichier JTL dans lequel consigner les résultats des échantillons. |
| -j | Nom du fichier journal d'exécution de JMeter. |
| -r | Exécutez le test dans les serveurs spécifiés par la propriété JMeter "remote_hosts". |
| -R | Liste des serveurs à distances. Exécuter le test sur les serveurs à distances spécifiés. |
| -g | Chemin vers le fichier CSV. Générer uniquement le tableau de bord du rapport. |
| -e | Générer un tableau de bord de rapport après le test de charge. |
| -o | Dossier de sortie où générer le tableau de bord du rapport après le test de charge. Le dossier ne doit pas exister ou être vide. |
Le script vous permet également de spécifier les informations facultatives du pare-feu/du serveur proxy :
| Options | Description |
|---|---|
| -H | Nom d'hôte ou adresse IP du serveur proxy. |
| -P | Port du serveur proxy. |
Exemple :
| jmeter -n -t my_test.jmx -l log.jtl -H my.proxy.server -P 8000 |
Si la propriété jmeterengine.stopfail.system.exit est définie sur true (la valeur par défaut est false), alors JMeter invoquera System.exit(1) s'il ne peut pas arrêter tous les processus léger. Normalement, ce n'est pas nécessaire.
Mode serveur
Pour les tests distribués, exécutez JMeter en mode serveur sur le ou les nouds distants, puis contrôlez le ou les serveurs à partir de l'interface graphique. Vous pouvez également utiliser le mode CLI pour exécuter des tests à distance. Pour démarrer le ou les serveurs, exécutez jmeter-server[.bat] sur chaque hôte de serveur.
Le script vous permet également de spécifier les informations facultatives du pare-feu/du serveur proxy :
| Options | Description |
|---|---|
| -H | Nom d'hôte ou adresse IP du serveur proxy |
| -P | Port du serveur proxy. |
Exemple :
| jmeter-server -H my.proxy.server -P 8000 |
Si vous souhaitez que le serveur se ferme après l'exécution d'un seul test, définissez la propriété JMeter server.exitaftertest=true.
Pour exécuter le test depuis le client en mode CLI, utilisez la commande suivante :
| jmeter -n -t testplan.jmx -r [-Gprop=val] [-Gglobal.properties] [-X] |
où :
| Options | Description |
|---|---|
| -G | Est utilisé pour définir les propriétés JMeter à définir dans les serveurs |
| -X | Signifie quitter les serveurs à la fin du test. |
| -Rserver1,server2 | Peut être utilisé à la place de -r pour fournir une liste de serveurs à démarrer. Remplace remote_hosts, mais ne définit pas la propriété. |
Si la propriété jmeterengine.remote.system.exit est définie sur true (la valeur par défaut est false), alors JMeter appellera System.exit(0) après avoir arrêté RMI à la fin d'un test. Normalement, ce n'est pas nécessaire.
Remplacement des propriétés via la ligne de commande
Les propriétés système Java et les propriétés JMeter peuvent être remplacées directement sur la ligne de commande (au lieu de modifier jmeter.properties). Pour ce faire, utilisez les options suivantes :
| Options | Description |
|---|---|
| -D[prop_name]=[value] | Définit une valeur de propriété système Java. |
| -J[prop_name]=[value] | Définit une propriété JMeter locale. |
| -G[prop_name]=[value] | Définit une propriété JMeter à envoyer à tous les serveurs à distances. |
| -G[propertyfile] | Définit un fichier contenant les propriétés JMeter à envoyer à tous les serveurs à distances. |
| -L[category]=[priority] | Remplace un paramètre de journalisation, en définissant une catégorie particulière sur le niveau de priorité donné. |
Le drapeau -L peut également être utilisé sans le nom de la catégorie pour définir le niveau de journalisation racine.
Exemples :
| jmeter -Duser.dir=/home/mstover/jmeter_stuff \ -Jremote_hosts=127.0.0.1 -Ljmeter.engine=DEBUG |
| jmeter -LDEBUG |
Les propriétés de la ligne de commande sont traitées au début du démarrage, mais après la configuration du système de journalisation.
Journalisation et messages d'erreur
Depuis la version 3.2, la journalisation JMeter n'est plus configurée via des fichiers de propriétés tels que jmeter.properties, mais elle est configurée via un fichier de configuration Apache Log4j2 (log4j2.xml dans le répertoire à partir duquel JMeter a été lancé, par défaut) à la place. De plus, chaque code, y compris JMeter et les plugiciels, doiT utiliser la bibliothèque SLF4J pour laisser les journaux depuis 3.2.
Voici un exemple de fichier log4j2.xml définissant deux appenders de journal et loggers pour chaque catégorie.
<Configuration status="WARN" packages="org.apache.jmeter.gui.logging">
<Appenders>
<!-- L'annexeur de fichier journal principal à jmeter.log dans le répertoire à partir duquel JMeter a été lancé, par défaut. -->
<File name="jmeter-log" fileName="${sys:jmeter.logfile:-jmeter.log}" append="false">
<PatternLayout>
<pattern>%d %p %c{1.}: %m%n</pattern>
</PatternLayout>
</File>
<!-- Appender de journal pour la visionneuse de journal GUI. Voir ci-dessous. -->
<GuiLogEvent name="gui-log-event">
<PatternLayout>
<pattern>%d %p %c{1.}: %m%n</pattern>
</PatternLayout>
</GuiLogEvent>
</Appenders>
<Loggers>
<!-- Enregistreur racine -->
<Root level="info">
<AppenderRef ref="jmeter-log" />
<AppenderRef ref="gui-log-event" />
</Root>
<!-- SNIP -->
<!--
# Exemples de journalisation Apache HttpClient
-->
<!-- # Activer le fil d'en-tête + la journalisation du contexte - Idéal pour le débogage -->
<!--
<Logger name="org.apache.http" level="debug" />
<Logger name="org.apache.http.wire" level="error" />
-->
<!-- SNIP -->
</Loggers>
</Configuration>
Ainsi, si vous souhaitez modifier le niveau de journalisation de la catégorie org.apache.http en niveau de débogage par exemple, vous pouvez simplement ajouter (ou décommenter) l'élément logger suivant dans le fichier log4j2.xml avant de lancer JMeter.
<Loggers>
<!-- SNIP -->
<Logger name="org.apache.http" level="debug" />
<!-- SNIP -->
</Loggers>
Pour plus de détails sur la configuration du fichier log4j2.xml, veuillez consulter la page Configuration d'Apache Log4j 2.
Le niveau de journalisation pour des catégories spécifiques ou l'enregistreur racine peut également être remplacé directement sur la ligne de commande (au lieu de modifier log4j2.xml). Pour ce faire, utilisez les options suivantes :
| Options | Description |
|---|---|
| -L[category]=[priority] | Remplace un paramètre de journalisation, en définissant une catégorie particulière sur le niveau de priorité donné. Depuis la version 3.2, il est recommandé d'utiliser un nom de catégorie complet (par exemple, org.apache.jmeter ou com.example.foo), mais si le nom de la catégorie commence par jmeter ou jorphan, org.apache. sera ajouté en interne à l'entrée du nom de catégorie pour construire un nom de catégorie complet (c'est-à-dire org.apache.jmeter ou org.apache.jorphan) pour la compatibilité descendante. |
Exemples :
| jmeter -Ljmeter.engine=DEBUG |
| jmeter -Lorg.apache.jmeter.engine=DEBUG |
| jmeter -Lcom.example.foo=DEBUG |
| jmeter -LDEBUG |
Différences dans la journalisation : anciennes et nouvelles pratiques :
Comme JMeter utilise SLF4J comme API de journalisation et Apache Log4j 2 comme cadre d'application de journalisation depuis la version 3.2, tous les niveaux de journalisation utilisés avant la version 3.2 ne peuvent pas correspondre exactement à l'un des nouveaux niveaux de journalisation disponibles fournis par SLF4J/Log4j2. Par conséquent, veuillez garder à l'esprit les différences suivantes et les nouvelles pratiques suggérées si vous devez migrer des configurations de journalisation existantes et du code de journalisation.
| Catégorie | Anciennes pratiques avant la version 3.2 | Nouvelles pratiques depuis la version 3.2 |
|---|---|---|
| Référence de l'enregistreur | Référence de l'enregistreur via LoggingManager :
|
Utilisez l'API SLF4J avec une catégorie ou une classe explicite :
|
| Niveaux de journalisation dans la configuration ou les arguments de ligne de commande | Anciens niveaux de journal :
|
Cartographie vers de nouveaux niveaux via SLF4J/Log4j2 :
Étant donné que FATAL_ERROR n'est pas pris en charge par l'API SLF4J, il est traité comme ERROR à la place pour que le code existant ne se casse pas. Il existe également l'option de niveau de journalisation FATAL. Le niveau TRACE, moins spécifique que DEBUG, est supporté en plus depuis la version 3.2. |
Le multimètre n'utilise généralement pas de boîtes de dialogue contextuelles pour les erreurs, car celles-ci interféreraient avec l'exécution des tests. Il ne signale pas non plus d'erreur pour une variable ou une fonction mal orthographiée ; à la place, la référence est simplement utilisée telle quelle.
Si JMeter détecte une erreur lors d'un test, un message sera écrit dans le fichier journal. Le nom du fichier journal est défini dans le fichier log4j2.xml (ou à l'aide de l'option -j, voir ci-dessous). Il est par défaut jmeter.log et se trouvera dans le répertoire à partir duquel JMeter a été lancé.
Le menu Options → Log Viewer affiche le fichier journal dans un volet inférieur de la fenêtre principale de JMeter.
En mode GUI, le nombre de messages d'erreur/fatal consignés dans le fichier journal s'affiche en haut à droite.
L'option de ligne de commande -j jmeterlogfile permet de traiter après la lecture du fichier de propriétés initial et avant que toute autre propriété ne soit traitée. Il permet donc de remplacer la valeur par défaut de jmeter.log. Les scripts jmeter qui prennent un nom de plan de test comme paramètre (par exemple jmeter-n.cmd) ont été mis à jour pour définir le fichier journal en utilisant le nom du plan de test, par exemple pour le plan de test Test27.jmx, le fichier journal est défini sur Test27.log.
Lors de l'exécution sous Windows, le fichier peut apparaître sous la forme jmeter, sauf si vous avez configuré Windows pour afficher les extensions de fichier. [Ce que vous devriez faire de toute façon, pour faciliter la détection des virus et autres méchants qui se font passer pour des fichiers texte...]
En plus d'enregistrer les erreurs, le fichier jmeter.log enregistre des informations sur l'exécution du test. Par exemple :
|
2017-03-01 12:19:20,314 INFO o.a.j.JMeter: Version 3.2.20170301 2017-03-01 12:19:45,314 INFO o.a.j.g.a.Load: Loading file: c:\mytestfiles\BSH.jmx 2017-03-01 12:19:52,328 INFO o.a.j.e.StandardJMeterEngine: Running the test! 2017-03-01 12:19:52,384 INFO o.a.j.e.StandardJMeterEngine: Starting 1 threads for group BSH. Ramp up = 1. 2017-03-01 12:19:52,485 INFO o.a.j.e.StandardJMeterEngine: Continue on error 2017-03-01 12:19:52,589 INFO o.a.j.t.JMeterThread: Thread BSH1-1 started 2017-03-01 12:19:52,590 INFO o.a.j.t.JMeterThread: Thread BSH1-1 is done 2017-03-01 12:19:52,691 INFO o.a.j.e.StandardJMeterEngine: Test has ended |
Le fichier journal peut être utile pour déterminer la cause d'une erreur, car JMeter n'interrompt pas un test pour afficher une boîte de dialogue d'erreur.
Liste complète des options de ligne de commande
Appeler JMeter en tant que "jmeter -?" affichera une liste de toutes les options de ligne de commande. Ceux-ci sont présentés ci-dessous :
| Options | Description |
|---|---|
| --? | Affiche les options de ligne de commande et quitter |
| -h, --help | Affiche les informations d'utilisation et quitter |
| -v, --version | Affiche les informations de version et quitter. |
| -p, --propfile argument | Le fichier de propriétés jmeter à utiliser. |
| -q, --addprop argument | Fichier(s) de propriétés JMeter supplémentaire(s) |
| -t, --testfile argument | Le fichier jmeter test(.jmx) à exécuter |
| -l, --logfile argument | Le fichier dans lequel consigner les échantillons |
| -i, --jmeterlogconf argument | Fichier de configuration de journalisation jmeter (log4j2.xml) |
| -j, --jmeterlogfile argument | Fichier journal d'exécution de jmeter (jmeter.log) |
| -n, --nongui | Exécuter JMeter en mode non graphique |
| -s, --server | Exécuter le serveur JMeter |
| -H, --proxyHost argument | Définir un serveur proxy pour JMeter à utiliser |
| -P, --proxyPort argument | Définir le port du serveur proxy pour JMeter à utiliser |
| -N, --nonProxyHosts argument | Définir la liste des hôtes non proxy (par exemple *.apache.org|localhost) |
| -u, --username argument | Définir le nom d'utilisateur pour le serveur proxy que JMeter doit utiliser |
| -a, --password argument | Définir le mot de passe pour le serveur proxy que JMeter doit utiliser |
| -J, --jmeterproperty argument=value | Définir des propriétés JMeter supplémentaires |
| -G, --globalproperty argument=value | Définir les propriétés globales (envoyées aux serveurs), par ex. -Gport=123 ou -Gglobal.properties |
| -D, --systemproperty argument=value | Définir des propriétés système supplémentaires |
| -S, --systemPropertyFile argument | Fichier(s) de propriétés système supplémentaire(s) |
| -f, --forceDeleteResultFile | forcer la suppression des fichiers de résultats existants et du dossier de rapport Web s'il est présent avant de commencer le test |
| -L, --loglevel argument=value | [category=]niveau par exemple jorphan=INFO, jmeter.util=DEBUG ou com.example.foo=WARN |
| -r, --runremote | Démarrer les serveurs à distances (comme défini dans remote_hosts) |
| -R, --remotestart argument | Démarrez ces serveurs à distances (remplace remote_hosts) |
| -d, --homedir argument | Le répertoire home de jmeter à utiliser |
| -X, --remoteexit | Quitter les serveurs à distances en fin de test (mode CLI) |
| -g, --reportonly argument | Générer un tableau de bord de rapport uniquement, à partir d'un fichier de résultats de test. |
| -e, --reportatendofloadtests | Générer un tableau de bord de rapport après le test de charge. |
| -o, --reportoutputfolder argument | Dossier de sortie pour le tableau de bord du rapport |
Remarque : le nom du fichier journal JMeter est formaté en tant que SimpleDateFormat (appliqué à la date actuelle) s'il contient des guillemets simples appariés, par exemple 'jmeter_'aaaaMMjjHHmmss'.log'
Si le nom spécial LAST est utilisé pour les indicateurs -t, -j ou -l, alors JMeter considère que cela signifie le dernier plan de test ayant été exécuté en mode interactif.
Mode d'arrêt CLI
Avant la version 2.5.1, JMeter appelait System.exit() lorsqu'un test en mode CLI était terminé. Cela a causé des problèmes pour les applications appelant JMeter directement, donc JMeter n'appelle plus System.exit() pour un test normal. [Certaines erreurs fatales peuvent encore appeler System.exit()] JMeter quittera tous les processus léger non-service qu'il démarre, mais il est possible que certains processus léger non-service restent ; ceux-ci empêcheront la JVM de se fermer. Pour détecter cette situation, JMeter démarre un nouveau processus léger de service juste avant de se fermer. Ce processus léger de service attend un court instant ; s'il revient de l'attente, il est clair que la JVM n'a pas pu quitter et le processus léger affiche un message pour dire pourquoi.
La propriété jmeter.exit.check.pause peut être utilisée pour configurer le délai avant l'affichage des processus léger non-service. S'il est défini sur 0 (valeur par défaut), JMeter n'affiche pas les processus léger non terminés à la fin du test.
Configuration de JMeter
Si vous souhaitez modifier les propriétés avec lesquelles JMeter s'exécute, vous devez soit modifier user.properties dans le répertoire /bin, soit créer votre propre copie de jmeter.properties et le spécifier dans la ligne de commande.
Remarque : Vous pouvez définir des propriétés JMeter supplémentaires dans le fichier défini par la propriété user.properties de JMeter ayant la valeur par défaut user.properties. Le fichier sera automatiquement chargé s'il se trouve dans le répertoire courant ou s'il se trouve dans le répertoire bin de JMeter. De même, system.properties est utilisé pour mettre à jour les propriétés système.
Paramètres
| Attribut | Description | Requis |
|---|---|---|
| ssl.provider | Vous pouvez spécifier la classe de votre implémentation SSL si vous ne souhaitez pas utiliser l'implémentation Java intégrée. | Non |
| xml.parser | Vous pouvez spécifier une implémentation en tant qu'analyseur XML. La valeur par défaut est : org.apache.xerces.parsers.SAXParser | Non |
| remote_hosts | Liste délimitée par des virgules des hôtes JMeter distants (ou host:port si nécessaire). Si vous exécutez JMeter dans un environnement distribué, répertoriez les machines sur lesquelles sont exécutés des serveurs distants JMeter. Cela vous permettra de contrôler ces serveurs à partir de l'interface graphique de cette machine. | Non |
| not_in_menu | Une liste des composants que vous ne voulez pas voir dans les menus de JMeter. Comme JMeter a de plus en plus de composants ajoutés, vous souhaiterez peut-être personnaliser votre JMeter pour n'afficher que les composants qui vous intéressent. Vous pouvez lister leur nom de classe ou leur étiquette de classe (la chaîne qui apparaît dans l'interface utilisateur de JMeter) ici, et ils ne seront pas n'apparaissent plus dans les menus. | Non |
| search_paths | Liste des chemins (séparés par ;) que JMeter recherchera pour les classes de plugiciel JMeter, par exemple des échantillonneurs supplémentaires. Un élément de chemin peut être soit un fichier jar, soit un répertoire. Tout fichier jar dans un tel répertoire sera automatiquement inclus dans search_paths, les fichiers jar dans les sous-répertoires sont ignorés. La valeur donnée s'ajoute à tous les fichiers jar trouvés dans le répertoire lib/ext. | Non |
| user.classpath | Liste des chemins que JMeter recherchera pour les classes de dépendance des utilitaires et des plugiciel. Utilisez le séparateur de chemin de votre plate-forme pour séparer plusieurs chemins. Un élément de chemin peut être soit un fichier jar, soit un répertoire. Tout fichier jar dans un tel répertoire sera automatiquement inclus dans user.classpath, les fichiers jar dans les sous-répertoires sont ignorés. La valeur donnée s'ajoute à tous les fichiers jar trouvés dans le répertoire lib. Toutes les entrées seront ajoutées au chemin de classe du chargeur de classe système et également au chemin du chargeur interne JMeter. | Non |
| plugin_dependency_paths | Liste des chemins (séparés par ;) que JMeter recherchera pour les classes de dépendance des utilitaires et des plugiciel. Un élément de chemin peut être soit un fichier jar, soit un répertoire. Tout fichier jar dans un tel répertoire sera automatiquement inclus dans plugin_dependency_paths, les fichiers jar dans les sous-répertoires sont ignorés. La valeur donnée s'ajoute à tous les fichiers jar trouvés dans le répertoire lib ou donnés par la propriété user.classpath. Toutes les entrées seront ajoutées au chemin du chargeur interne JMeter uniquement. Pour les dépendances de plugin, l'utilisation de plugin_dependency_paths doit être préférée à user.classpath. | Non |
| user.properties | Nom du fichier contenant des propriétés JMeter supplémentaires. Celles-ci sont ajoutées après le fichier de propriétés initial, mais avant que les options -q et -J ne soient traitées. | Non |
| system.properties | Nom du fichier contenant des propriétés système supplémentaires. Ceux-ci sont ajoutés avant que les options -S et -D ne soient traitées. | Non |
Les options de ligne de commande et les fichiers de propriétés sont traités dans l'ordre suivant :
- -p fileprop
- jmeter.properties (ou le fichier de l'option -p) est alors chargé
- -j logfile
- La journalisation est initialisée
- user.properties est chargé
- system.properties est chargé
- toutes les autres options de ligne de commande sont traitées
Voir également les commentaires dans les fichiers jmeter.properties, user.properties et system.properties pour plus d'informations sur les autres paramètres que vous pouvez modifier.