13. Test à distance

13.1 Configuration de SSL ¶

La configuration la plus simple consiste à utiliser une paire clé/certificat pour tous les serveurs et clients JMeter que vous souhaitez connecter. JMeter est livré avec un script pour générer un magasin de clés qui contient une clé (et son certificat correspondant) nommée rmi . Le script se trouve dans le répertoire bin et est disponible pour les systèmes Windows (appelé bin/create-rmi-keystore.bat ) et les systèmes de type Unix (appelé bin/create-rmi-keystore.sh ). Il générera une paire de clés, valide pendant sept jours, avec une phrase de passe par défaut de valeur « changeit ». Il est conseillé de l'appeler depuis le répertoire bin .

Lorsque vous exécutez le script, il vous posera des questions sur certains noms qu'il intégrera dans le certificat. Vous pouvez taper ce que vous voulez, tant que l'outil keystore l'accepte. Cette valeur doit correspondre à la propriété server.rmi.ssl.keystore.alias , qui par défaut est rmi . Un exemple de session pour créer le magasin de clés est présenté ci-dessous.

$ cd jmètre/bin
$ ./create-rmi-keystore.sh
Quel est votre nom et prénom ?
  [Inconnu] : rmi
Quel est le nom de votre unité organisationnelle?
  [Inconnu] : Nom de mon unité
Quel est le nom de votre organisation ?
  [Inconnu] : le nom de mon organisation
Quel est le nom de votre Ville ou Localité ?
  [Inconnu] : votre ville
Quel est le nom de votre état ou province ?
  [Inconnu] : votre état
Quel est le code pays à deux lettres de cet appareil ?
  [Inconnu] : XY
Est-ce que CN=rmi, OU=nom de mon unité, O=nom de mon organisation, L=votre ville, ST=votre état, C=XY est correct ?
  [non Oui

Copiez le fichier rmi_keystore.jks généré dans le dossier jmeter/bin ou référencez-le dans la propriété 'server.rmi.ssl.keystore.file'

Les paramètres par défaut pour RMI devraient fonctionner avec cette configuration. Copiez le fichier bin/rmi_keystore.jks sur chaque serveur et client JMeter que vous souhaitez utiliser pour votre configuration de test distribué.

13.2 Le faire manuellement ¶

Dans certains cas, le script jmeter-server peut ne pas fonctionner pour vous (si vous utilisez une plate-forme de système d'exploitation non prévue par les développeurs JMeter). Voici comment démarrer les serveurs JMeter (étape 1 ci-dessus) avec un processus plus manuel :

Étape 1a : Démarrez le registre RMI

Depuis JMeter 2.3.1, le registre RMI est démarré par le serveur JMeter, donc cette section ne s'applique pas dans le cas normal. Pour revenir au comportement précédent, définissez la propriété JMeter server.rmi.create=false sur les systèmes hôtes du serveur et suivez les instructions ci-dessous.

JMeter utilise Remote Method Invocation (RMI) comme mécanisme de communication à distance. Par conséquent, vous devez exécuter l'application RMI Registry (nommée " rmiregistry ") fournie avec le JDK et située dans le répertoire " bin ". Avant d'exécuter rmiregistry , assurez-vous que les fichiers jar suivants se trouvent dans votre chemin de classe système :

• JMETER_HOME/lib/ext/ApacheJMeter_core.jar
• JMETER_HOME/lib/jorphan.jar
• JMETER_HOME/lib/logkit-2.0.jar

Étape 1b : Démarrez le serveur JMeter

Une fois l'application RMI Registry en cours d'exécution, démarrez le serveur JMeter. Utilisez l'option " -s " avec le script de démarrage jmeter (" jmeter -s ").

Les étapes 2 et 3 restent les mêmes.

13.3 Astuces ¶

JMeter/RMI nécessite une connexion du client au serveur. Cela utilisera le port que vous avez choisi, 1099 par défaut .
JMeter/RMI nécessite également une connexion inversée afin de renvoyer les résultats des échantillons du serveur au client.
Ceux-ci utiliseront des ports à numéro élevé.
Ces ports peuvent être contrôlés par la propriété jmeter appelée client.rmi.localport dans jmeter.properties .
S'il est différent de zéro, il sera utilisé comme base pour les numéros de port locaux pour le moteur client. Pour le moment, JMeter ouvrira jusqu'à trois ports en commençant par le port défini dans client.rmi.localport. S'il existe des pare-feu ou d'autres filtres réseau entre le client et le serveur JMeter, vous devrez vous assurer qu'ils sont configurés pour autoriser les connexions. Si nécessaire, utilisez un logiciel de surveillance pour afficher le trafic généré.

Si vous utilisez Suse Linux, ces conseils peuvent vous aider. L'installation par défaut peut activer le pare-feu. Dans ce cas, le test à distance ne fonctionnera pas correctement. Les conseils suivants ont été fournis par Sergey Ten.

Si vous voyez des connexions refusées, activez le débogage en transmettant les options suivantes.

rmiregistry -J-Dsun.rmi.log.debug=true \
     -J-Dsun.rmi.server.exceptionTrace=true \
     -J-Dsun.rmi.loader.logLevel=verbeux \
     -J-Dsun.rmi.dgc.logLevel=verbeux \
     -J-Dsun.rmi.transport.logLevel=verbeux \
     -J-Dsun.rmi.transport.tcp.logLevel=verbeux \

Depuis JMeter 2.3.1, le registre RMI est démarré par le serveur ; cependant, les options peuvent toujours être transmises à partir de la ligne de commande JMeter. Par exemple : " jmeter -s -Dsun.rmi.loader.logLevel=verbose " (c'est-à-dire omettre les préfixes -J ). Alternativement, les propriétés peuvent être définies dans le fichier system.properties .

La solution au problème consiste à supprimer les loopbacks 127.0.0.1 et 127.0.0.2 de /etc/hosts . Ce qui se passe, c'est que jmeter-server ne peut pas se connecter à rmiregistry si le bouclage 127.0.0.2 n'est pas disponible. Utilisez les paramètres suivants pour résoudre le problème.

Remplacer

`dirname $0`/jmeter -s "$@"

Avec

HOST="-Djava.rmi.server.hostname=[nom_ordinateur][domaine_ordinateur] \
      -Djava.security.policy=`dirname $0`/[policy_file]" \
`dirname $0`/jmeter $HOST -s "$@"

Créez également un fichier de stratégie et ajoutez la ligne [computer_name][computer_domain] à /etc/hosts .

Afin de mieux prendre en charge la tunnellisation SSH des canaux de communication RMI utilisés dans les tests à distance, depuis JMeter 2.6 :

• une nouvelle propriété " client.rmi.localport " peut être définie pour contrôler le port RMI utilisé par RemoteSampleListenerImpl
• Pour prendre en charge la tunnellisation du trafic RMI sur un tunnel SSH en tant que point de terminaison distant à l'aide d'un port sur la machine locale, l'interface de bouclage est désormais autorisée à être utilisée si elle a été spécifiée directement à l'aide du paramètre Java System Property " java.rmi.server.hostname " .

13.4 Utilisation d'un port différent ¶

Par défaut, JMeter utilise le port RMI standard 1099 . Il est possible de changer cela. Pour que cela fonctionne avec succès, tous les éléments suivants doivent être d'accord :

• Sur le serveur, démarrez rmiregistry en utilisant le nouveau numéro de port
• Sur le serveur, démarrez JMeter avec la propriété server_port définie
• Sur le client, mettez à jour la propriété remote_hosts pour inclure les nouveaux paramètres hôte distant :port

Depuis JMeter 2.1.1, les scripts jmeter-server prennent en charge la modification du port. Par exemple, supposons que vous souhaitiez utiliser le port 1664 (peut-être que 1099 est déjà utilisé).

C:\JMETER> SET SERVER_PORT=1664
C:\JMETER> JMETER-SERVER [autres options]

$ SERVER_PORT=1664 jmeter-server [autres options]

Dans les deux cas, le script démarre rmiregistry sur le port spécifié, puis démarre JMeter en mode serveur, après avoir défini la propriété « server_port ».

Le port choisi sera enregistré dans le fichier jmeter.log du serveur ( rmiregistry ne crée pas de fichier journal).

13.5 Utilisation d'un expéditeur d'échantillon différent ¶

Les écouteurs du plan de test renvoient leurs résultats au client JMeter qui écrit les résultats dans les fichiers spécifiés. Par défaut, les échantillons sont renvoyés de manière synchrone au fur et à mesure qu'ils sont générés. Cela peut affecter le débit maximal du test du serveur ; le résultat de l'échantillon doit être renvoyé avant que le thread puisse continuer. Certaines propriétés JMeter peuvent être définies pour modifier ce comportement.

mode

mode d'envoi d'échantillons - la valeur par défaut est StrippedBatch depuis la version 2.9. Cela doit être défini sur le poste client.

Standard

envoyer des échantillons de manière synchrone dès qu'ils sont générés

Tenir

conserver les échantillons dans un tableau jusqu'à la fin d'une analyse. Cela peut utiliser beaucoup de mémoire sur le serveur et est déconseillé.

DiskStore

stocker les échantillons dans un fichier disque (sous java.io.temp ) jusqu'à la fin d'une exécution. Le fichier de données sérialisé est supprimé à la sortie de la JVM.

StrippedDiskStore

supprimez responseData des échantillons réussis et utilisez l'expéditeur DiskStore pour les envoyer.

Lot

envoyer des échantillons enregistrés lorsque le nombre ( num_sample_threshold ) ou le temps ( time_threshold ) dépasse un seuil, auquel cas les échantillons sont envoyés de manière synchrone. Les seuils peuvent être configurés sur le serveur à l'aide des propriétés suivantes :

num_sample_threshold

nombre d'échantillons à accumuler, par défaut 100

time_threshold

seuil de temps, par défaut 60000 ms = 60 secondes

Voir aussi le mode Asynch, décrit ci-dessous.

Statistique

envoyer un échantillon récapitulatif lorsque le nombre ou le temps dépasse un seuil. Les exemples sont résumés par nom de groupe de threads et étiquette d'échantillon. Les champs suivants sont cumulés :

• temps écoulé
• latence
• octets
• nombre d'échantillons
• nombre d'erreurs

Les autres champs qui varient d'un échantillon à l'autre sont perdus.

Dépouillé

supprimer responseData des échantillons réussis

StrippedBatch

supprimez responseData des échantillons réussis et utilisez Batch sender pour les envoyer.

Asynch

les échantillons sont temporairement stockés dans une file d'attente locale. Un thread de travail distinct envoie les échantillons. Cela permet au thread de test de continuer sans attendre que le résultat soit renvoyé au client. Cependant, si les échantillons sont créés plus rapidement qu'ils ne peuvent être envoyés, la file d'attente finira par se remplir et le thread de l'échantillonneur se bloquera jusqu'à ce que certains échantillons puissent être évacués de la file d'attente. Ce mode est utile pour lisser les pics de génération d'échantillons. La taille de la file d'attente peut être ajustée en définissant la propriété JMeter asynch.batch.queue.size ( 100 par défaut ) sur le nœud du serveur.

DépouilléAsynchrone

supprimez responseData des échantillons réussis et utilisez Async sender pour les envoyer.

Implémentation personnalisée

définissez le paramètre mode sur votre nom de classe d'expéditeur d'échantillon personnalisé. Celui-ci doit implémenter l'interface SampleSender et avoir un constructeur qui prend un seul paramètre de type RemoteSampleListener .

Les propriétés suivantes s'appliquent aux modes Lot et Statistique :

num_sample_threshold

nombre d'échantillons dans un lot ( 100 par défaut )

time_threshold

nombre de millisecondes à attendre (par défaut 60 secondes)

13.6 Traitement des nœuds dont le démarrage a échoué ¶

Pour les tests à grande échelle, il est possible qu'une partie des serveurs distants soit indisponible ou en panne. Par exemple, lorsque vous utilisez un script d'automatisation pour allouer de nombreuses machines cloud et les utilisez comme générateurs, certaines des machines demandées peuvent échouer au démarrage en raison de problèmes de cloud. Depuis JMeter 2.13, de nouvelles propriétés permettent de contrôler ce comportement.

Tout d'abord, vous voudrez peut-être réessayer les tentatives d'initialisation dans l'espoir que les nœuds défaillants retardent légèrement leur démarrage. Pour activer les tentatives, vous devez définir la propriété client.tries sur le nombre total de tentatives de connexion. Par défaut, il ne fait qu'une seule tentative. Pour contrôler le délai de nouvelle tentative, définissez la propriété client.retries_delay sur le nombre de millisecondes de veille entre les tentatives.

Enfin, vous voudrez peut-être toujours exécuter le test avec les générateurs qui ont réussi l'initialisation et en ignorant les nœuds défaillants. Pour activer cela, définissez la propriété client.continue_on_fail=true .

13.7 Utilisation d'un gestionnaire de sécurité ¶

Lorsque vous exécutez JMeter dans un environnement distribué, vous devez être conscient que JMeter est essentiellement un agent d'exécution à distance côté serveur et côté client. Cela pourrait être utilisé par une partie malveillante pour obtenir un accès supplémentaire, une fois qu'elle a compromis l'un des clients ou serveurs JMeter. Pour atténuer cela, Java utilise le concept d'un gestionnaire de sécurité qui est interrogé par la JVM avant que des actions dangereuses potentielles ne soient exécutées. Ces actions peuvent être la résolution de noms d'hôte, la création ou la lecture de fichiers ou l'exécution de commandes dans le système d'exploitation.

Le gestionnaire de sécurité peut être activé en définissant les propriétés système Java java.security.manager et java.security.policy . N'oubliez pas de jeter un coup d'œil à la visite guidée du contrôle des applications .

En utilisant le nouveau mécanisme de setenv.sh (ou setenv.bat sous Windows), vous pouvez activer le gestionnaire de sécurité en ajoutant l'extrait de code suivant à ${JMETER_HOME}/bin/setenv.sh :

JVM_ARGS="\
   -Djava.security.manager \
   -Djava.security.policy=${JMETER_HOME}/bin/java.policy \
   -Djmeter.home=${JMETER_HOME} \
"

La JVM va maintenant ajouter les politiques définies dans le fichier ${JMETER_HOME}/bin/java.policy aux politiques éventuellement définies globalement. Si vous souhaitez que votre définition soit la seule source de stratégies, utilisez deux signes égal au lieu d'un lors de la définition de la propriété java.security.policy .

Les politiques dépendront de votre cas d'utilisation et cela peut prendre un certain temps pour trouver les bonnes actions restreintes et autorisées. Java peut vous aider à trouver les stratégies nécessaires avec la propriété java.security.debug . Réglez-le sur access et il enregistrera toutes les autorisations qu'il est invité à autoriser. Ajoutez simplement la ligne suivante à votre setenv.sh :

JVM_ARGS="${JVM_ARGS} -Djava.security.debug=accès"

Cela peut sembler un peu étrange que nous définissions une propriété système Java jmeter.home avec la valeur de ${JMETER_HOME} . Cette variable sera utilisée dans l'exemple java.policy pour limiter l'accès au système de fichiers et lui permettre uniquement de lire la configuration et les bibliothèques JMeters et de restreindre l'accès en écriture à des emplacements spécifiques uniquement.

Le fichier de définition de stratégie suivant a été utilisé pour un simple test à distance. Vous devrez probablement modifier les politiques lorsque vous exécuterez des scénarios plus complexes. Les plans de test sont placés quelque part dans le répertoire personnel des utilisateurs sous un répertoire appelé jmeter-testplans . L'exemple java.policy ressemble à :

accorder codeBase "file:${jmeter.home}/bin/*" {
  autorisation java.security.AllPermission ;
} ;

accorder codeBase "file:${jmeter.home}/lib/jorphan.jar" {
  autorisation java.security.AllPermission ;
} ;

accorder codeBase "file:${jmeter.home}/lib/log4j-api-2.11.1.jar" {
  autorisation java.security.AllPermission ;
} ;

accorder codeBase "file:${jmeter.home}/lib/log4j-slf4j-impl-2.11.1.jar" {
  autorisation java.security.AllPermission ;
} ;

accorder codeBase "file:${jmeter.home}/lib/slf4j-api-1.7.25.jar" {
  autorisation java.security.AllPermission ;
} ;

accorder codeBase "file:${jmeter.home}/lib/log4j-core-2.11.1.jar" {
  autorisation java.security.AllPermission ;
} ;

accorder codeBase "file:${jmeter.home}/lib/ext/*" {
  autorisation java.security.AllPermission ;
} ;

accorder codeBase "file:${jmeter.home}/lib/httpclient-4.5.6.jar" {
  autorisation java.net.SocketPermission "*", "connecter, résoudre" ;
} ;

accorder codeBase "file:${jmeter.home}/lib/darcula.jar" {
  autorisation java.lang.RuntimePermission "modifyThreadGroup" ;
} ;

accorder codeBase "file:${jmeter.home}/lib/xercesImpl-2.12.0.jar" {
  permission java.io.FilePermission "${java.home}/lib/xerces.properties", "read" ;
} ;

accorder codeBase "file:${jmeter.home}/lib/groovy-all-2.4.15.jar" {
  autorisation groovy.security.GroovyCodeSourcePermission "/groovy/script" ;
  autorisation java.lang.RuntimePermission "accessClassInPackage.sun.reflect" ;
  autorisation java.lang.RuntimePermission "getProtectionDomain" ;
} ;

accorder {
  autorisation java.io.FilePermission "${jmeter.home}/backups", "lecture, écriture" ;
  permission java.io.FilePermission "${jmeter.home}/backups/*", "lecture, écriture, suppression" ;
  permission java.io.FilePermission "${jmeter.home}/bin/upgrade.properties", "read" ;
  permission java.io.FilePermission "${jmeter.home}/lib/ext/-", "read" ;
  permission java.io.FilePermission "${jmeter.home}/lib/ext", "read" ;
  autorisation java.io.FilePermission "${jmeter.home}/lib/-", "lire" ;
  permission java.io.FilePermission "${user.home}/jmeter-testplans/-", "lecture, écriture" ;
  autorisation java.io.SerializablePermission "enableSubclassImplementation" ;
  autorisation java.lang.reflect.ReflectPermission "suppressAccessChecks" ;
  autorisation java.lang.RuntimePermission "accessClassInPackage.jdk.internal.dynalink.support" ;
  autorisation java.lang.RuntimePermission "accessClassInPackage.sun.awt" ;
  autorisation java.lang.RuntimePermission "accessClassInPackage.sun.misc" ;
  autorisation java.lang.RuntimePermission "accessClassInPackage.sun.swing" ;
  autorisation java.lang.RuntimePermission "accessDeclaredMembers" ;
  autorisation java.lang.RuntimePermission "createClassLoader" ;
  autorisation java.lang.RuntimePermission "createSecurityManager" ;
  autorisation java.lang.RuntimePermission "getClassLoader" ;
  permission java.lang.RuntimePermission "getenv.*" ;
  autorisation java.lang.RuntimePermission "nashorn.createGlobal" ;
  autorisation java.util.PropertyPermission "*", "lire" ;
} ;