1.0.4 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 exemple Web (HTTP/HTTPS), FTP, JDBC, LDAP, Java, JUnit, etc.

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 Création d'un plan de test 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 Création d'un plan de test Web . Les autres sections spécifiques du plan de test sont :

• Plan de test Web avancé
• JDBCName
• FTP
• Point à point JMS
• Rubrique JMS
• LDAP
• LDAP étendu
• Webservices (SOAP)

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.

1.1.1 Version Java ¶

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

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

Les systèmes d'exploitation testés avec JMeter peuvent être consultés sur cette page du wiki JMeter.

Même si votre système d'exploitation n'est pas répertorié sur la page wiki, JMeter devrait s'y exécuter à condition que la JVM soit conforme.

1.2.1 Compilateur Java ¶

Si vous souhaitez créer la source JMeter ou développer des plugins JMeter, vous aurez besoin d'un JDK 8 ou supérieur entièrement compatible.

1.2.2 Analyseur XML SAX ¶

JMeter est livré avec l' analyseur Xerces XML 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 classpath de JMeter et mettez à jour le fichier jmeter.properties avec le nom de classe complet de l'implémentation de l'analyseur.

1.2.3 Assistance par e-mail ¶

JMeter dispose de fonctionnalités de messagerie étendues. Il peut envoyer des e-mails en fonction des résultats des tests et dispose d'un échantillonneur POP3(S)/IMAP(S). Il dispose également d'un échantillonneur SMTP(S).

1.2.4 Chiffrement 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 packages de chiffrement nécessaires dans le classpath 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é, etc. 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 SSL Manager , pour un meilleur contrôle des certificats.

L'échantillonneur SMTP peut éventuellement utiliser un magasin de confiance local ou approuver tous les certificats.

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

1.2.6 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. Veuillez vous référer à leur documentation pour plus de détails. Il peut également y avoir des informations sur le JMeter Wiki .

1.2.7 Bibliothèques pour ActiveMQ JMS ¶

Vous devrez ajouter le jar activemq-all-XXXjar à votre classpath, par exemple en le stockant dans le répertoire lib/ .

Voir la page de configuration initiale d'ActiveMQ pour plus de détails.

1.4.1 Classpath de JMeter ¶

JMeter trouve automatiquement les classes des jars dans les répertoires suivants :

JMETER_HOME/lib

utilisé pour les bocaux utilitaires

JMETER_HOME/lib/ext

utilisé pour les composants et plugins JMeter

Si vous avez développé de nouveaux composants JMeter, vous devez les jar et copier le jar dans le répertoire lib/ext de JMeter . JMeter trouvera automatiquement les composants 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 fichiers jar 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, etc.) 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 fichiers jar (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 .

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

1.4.2 Créer un plan de test à partir d'un modèle ¶

Vous avez la possibilité de créer un nouveau plan de test à partir d'un modèle existant.

Pour cela, utilisez le menu Fichier  →  Modèles… ou l'icône Modèles :

Une popup apparaît, vous pouvez alors choisir un template parmi la liste :

Certains modèles 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 Valider et le modèle sera créé.

Une documentation pour chaque modèle explique ce qu'il faut faire une fois le plan de test créé à partir du modèle.

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

-E

[schéma proxy à utiliser - facultatif - pour non-http]

-H

[nom d'hôte ou adresse IP du serveur proxy]

-P

[port du serveur proxy]

-N

[hôtes non proxy] (par exemple *.apache.org|localhost )

-u

[nom d'utilisateur pour l'authentification proxy - si nécessaire]

-un

[mot de passe pour l'authentification proxy - si nécessaire]

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

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

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

-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 distants] Exécuter le test sur les serveurs distants 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 :

-H

[nom d'hôte ou adresse IP du serveur proxy]

-P

[port du serveur proxy]

jmeter -n -t mon_test.jmx -l log.jtl -H mon.proxy.serveur -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 threads. Normalement, ce n'est pas nécessaire.

1.4.5 Mode serveur ¶

Pour les tests distribués , exécutez JMeter en mode serveur sur le ou les nœuds 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(s) serveur(s), 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 :

-H

[nom d'hôte ou adresse IP du serveur proxy]

-P

[port du serveur proxy]

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]

-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

-Rserveur1,serveur2

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 invoquera System.exit(0) après avoir arrêté RMI à la fin d'un test. Normalement, ce n'est pas nécessaire.

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

-D[prop_name]=[valeur]

définit une valeur de propriété système Java.

-J[prop_name]=[valeur]

définit une propriété JMeter locale.

-G[prop_name]=[valeur]

définit une propriété JMeter à envoyer à tous les serveurs distants.

-G[fichierpropriété]

définit un fichier contenant les propriétés JMeter à envoyer à tous les serveurs distants.

-L[catégorie]=[priorité]

remplace un paramètre de journalisation, en définissant une catégorie particulière sur le niveau de priorité donné.

L' indicateur -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

jmètre -LDEBUG

1.4.7 Journalisation et messages d'erreur ¶

Voici un exemple de fichier log4j2.xml qui définit deux appenders de journal et loggers pour chaque catégorie.

<Configuration status="WARN" packages="org.apache.jmeter.gui.logging">

  <Appendices>

    <!-- L'ajout 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">
      <Mise en page du motif>
        <motif>%d %p %c{1.} : %m%n</motif>
      </PatternLayout>
    </Fichier>

    <!-- Appender de journal pour la visionneuse de journal GUI. Voir ci-dessous. -->
    <GuiLogEvent name="gui-log-event">
      <Mise en page du motif>
        <motif>%d %p %c{1.} : %m%n</motif>
      </PatternLayout>
    </GuiLogEvent>

  </Appendices>

  <Enregistreurs>

    <!-- Enregistreur racine -->
    <Niveau racine="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 -->

  </Enregistreurs>

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

  <Enregistreurs>
    <!-- SNIP -->
    <Logger name="org.apache.http" level="debug" />
    <!-- SNIP -->
  </Enregistreurs>

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 :

-L[catégorie]=[priorité]

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 une compatibilité descendante.

Exemples :

jmeter -Ljmeter.engine=DÉBOGAGE

jmeter -Lorg.apache.jmeter.engine=DEBUG

jmeter -Lcom.example.foo=DEBUG

jmètre -LDEBUG

Différences dans la journalisation : anciennes vs nouvelles pratiques :

Comme JMeter utilise SLF4J comme API de journalisation et Apache Log4j 2 comme framework 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.

LoggingManager.getLoggerFor(catégorie Chaîne);
LoggingManager.getLoggerForClass();

LoggerFactory.getLogger(catégorie String);
LoggerFactory.getLogger(Foo.class);

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

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 oajJMeter : Version 3.2.20170301
2017-03-01 12:19:45,314 INFO oajgaLoad : Chargement du fichier : c:\mytestfiles\BSH.jmx
2017-03-01 12:19:52,328 INFO oajeStandardJMeterEngine : Exécution du test !
2017-03-01 12:19:52,384 INFO oajeStandardJMeterEngine : Démarrage de 1 threads pour le groupe BSH. Accélération = 1.
2017-03-01 12:19:52,485 INFO oajeStandardJMeterEngine : Continuer en cas d'erreur
2017-03-01 12:19:52,589 INFO oajtJMeterThread : Thread BSH1-1 démarré
2017-03-01 12:19:52,590 INFO oajtJMeterThread : le thread BSH1-1 est terminé
2017-03-01 12:19:52,691 INFO oajeStandardJMeterEngine : Le test est terminé

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.

1.4.8 Liste complète des options de ligne de commande ¶

L' appel de JMeter en tant que " jmeter -? " imprimera une liste de toutes les options de ligne de commande. Ceux-ci sont présentés ci-dessous.

    --?
        imprimer les options de ligne de commande et quitter
    -h, --help
        imprimer les informations d'utilisation et quitter
    -v, --version
        imprimer 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 nongui
    -s, --serveur
        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>=<valeur>
        Définir des propriétés JMeter supplémentaires
    -G, --globalproperty <argument>=<valeur>
        Définir les propriétés globales (envoyées aux serveurs)
        par exemple -Gport=123
         ou -Gglobal.properties
    -D, --systemproperty <argument>=<valeur>
        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>=<valeur>
        [category=]niveau par exemple jorphan=INFO, jmeter.util=DEBUG ou com.example.foo=WARN
    -r, --runremote
        Démarrer les serveurs distants (comme défini dans remote_hosts)
    -R, --remotestart <argument>
        Démarrez ces serveurs distants (remplace remote_hosts)
    -d, --homedir <argument>
        le répertoire personnel de jmeter à utiliser
    -X, --remoteexit
        Quitter les serveurs distants 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_'yyyyMMddHHmmss'.log '

Si le nom spécial LAST est utilisé pour les drapeaux -t , -j ou -l , alors JMeter considère que cela signifie le dernier plan de test qui a été exécuté en mode interactif.

1.4.9 Arrêt du mode 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 qui invoquent JMeter directement, donc JMeter n'invoque plus System.exit() pour un test normal. [Certaines erreurs fatales peuvent encore invoquer System.exit() ] JMeter quittera tous les threads non-démons qu'il démarre, mais il est possible que certains threads non-démons restent ; ceux-ci empêcheront la JVM de se fermer. Pour détecter cette situation, JMeter démarre un nouveau thread démon juste avant de se terminer. Ce thread démon attend un court instant ; s'il revient de l'attente, il est clair que la JVM n'a pas pu quitter et le thread imprime un message pour dire pourquoi.

La propriété jmeter.exit.check.pause peut être utilisée pour remplacer la pause par défaut de 2000ms (2secs). S'il est défini sur 0 , JMeter ne démarre pas le thread démon.