L’une des principales caractéristiques de JMeter est la exécution distribuée, qui permet une croissance horizontale du nombre d’exécutrices. Bien que ce soit un peu moins connu, il est très utile ou efficace lorsque nous devons exécuter seulement quelques milliers de threads ou utilisateurs virtuels.

Pourquoi elle est peu connue ? #

Elle en fait vraiment peu de cas car il existe des entreprises spécialisées qui fournissent cette automatisation dans la cloud sous forme de Flood.io, Blazemeter et Octoperf parmi d’autres. De plus, il peut être une tâche laborieuse qui consomme beaucoup de temps ; il faudrait un évaluation du coût-bénéficier de l’implémentation de cette méthode pour certains cas particuliers.

Quand il est judicieux d’engager le temps ? #

Si vous devez effectuer une charge ou un essai de stress entre 2.000 et 8.000 threads ou utilisateurs virtuels, je recommande cette approche. Au-delà de ce seuil, je ne conseille pas car créer, duplicer, configurer et surveiller les générateurs de charges, surtout si c’est un seul individu qui est chargé de toutes ces tâches, peut prendre beaucoup de temps, même s’il n’est responsable que d’eux. Pour des exécutions supérieures à 8K, je vous recommande d’explorer les options Cloud SaaS Load Testing comme nous l’avons mentionné précédemment ou également utiliser les conteneurs, qui seront une partie de cette série sur la JMeter en tant que générateur distribué.

Comment ça fonctionne ? #

Il opère en mode master-slave, ce qui signifie qu’il faut un noeud ou une serveur à la fois pour être le conteneur/organisateur et les autres serveurs seront des nœuds/injecteurs de charge (les générateurs de charge générateurs de charge). Cette schéma fonctionne uniquement sur la même réseau, ce qui signifie que nous aurions dû subdivider tous les appareils pour qu’ils soient interconnectés. Sans plus tarder, allons voir ce dont nous avons besoin :

• Controleur, aussi connu sous le nom de Maître ou Orchestrateur (Windows) x 1
  • Firewall désactivé
  • Java 1.8+
  • JMeter 5.2.1
• Node, aussi appelé Load Injector (Linux Ubuntu) x 4
  • Java 1.8+
  • JMeter 5.2.1

La version de JMeter 5.2.1 doit être la même sur tous les machines, le niveau de Java est différent dans le noeud mère par rapport aux nœuds, mais il est recommandé d’utiliser le même niveau de Java sur toutes les machines.

Recette de cuisine #

1.- Filtre de sécurité - Gestionnaire #

Nous devons désactiver le pare-feu Windows pour permettre des connexions bidirectionnelles entre la maîtresse et les nœuds. Choisissez Windows Server 2019 pour cet exemple car il est plus facile de montrer l’exécution dans un environnement graphique, bien que vous puissiez également utiliser une interface utilisateur Linux (GUI). Il est possible d’y faire cela à partir du CLI aussi bien que par la commande ligne de commandes (CLI), je fournirai un exemple qui serait très utile si aucune interface graphique n’était disponible ou pour ceux qui aiment CLI.

2.- Java - Controleur #

Installez Java 1.8+ pour cet exemple, j’ai utilisé la version JRE de Java 1.8, vous pouvez télécharger la dernière version de Java ici.

3.- JMeter - Controleur #

Téléchargez et installez JMeter 5.2.1 (la version la plus récente connue jusqu’à cette publication), si vous avez des doutes, vous pouvez voir ce publication. Si vous avez besoin de plugins ou des fichiers de données (CSV ou images), vous devrez les installer manuellement dans chaque générateur de tests de charge, car ces fichiers ne sont pas transmis via RMI.

4.- Propriétés - Contrôleur #

Editer le fichier jmeter.properties pour ajouter les adresses IP des hôtes ou des nœuds (voir étape #6) et également pour désactiver la sécurité RMI. C’est un processus plus long, mais nous allons commencer par l’itinéraire le plus simple.

#remote_hosts=127.0.0.1  //original

remote_hosts=10.223.2.71,10.223.2.78,10.223.2.63,10.223.2.58  //editada

#server.rmi.ssl.disable=false   //original

server.rmi.ssl.disable=true     //editada

5.- Java - Nœuds #

Installez Java 1.8+ sur chaque noeud, même si vous utilisez des services cloud, je recommande de faire ce tâche une seule fois et d’en créer une image pour générer les autres serveurs à partir de cette image. Bien que dans tous les cas vous aurez besoin de vérifier les étapes suivantes pour chaque node. Pour cet exemple, j’ai utilisé Linux Ubuntu, voici un recette pour l’installation.

6.- JMeter - Nœuds #

Téléchargez et installez JMeter 5.2.1 (la dernière version connue jusqu’à cette publication), si vous avez des doutes, vous pouvez voir ce publication. Nous pouvons utiliser un simple wget pour télécharger le ball tar, pour décompresser il nous faut utiliser la commande tar.

wget https://downloads.apache.org//jmeter/binaries/apache-jmeter-5.2.1.tgz

tar -xvf apache-jmeter-5.2.1.tgz

7.- Adresse IP - Nœuds #

Pour obtenir l’adresse IP de chaque serveur node pour insertion dans le pas #4, cela peut sembler récursif, mais cette valeur est nécessaire pour les étapes #4 et #9. La méthode la plus simple consiste à utiliser le commande ifconfig, comme illustré ci-dessous:

L’adresse IP serait : 10.223.2.71

8.- Propriétés - Node #

Edit le fichier jmeter.properties dans les nœuds pour désactiver la sécurité RMI. Comme indiqué précédemment, il s’agit d’un processus un peu plus long pour activer la sécurité, mais étant donné que nous sommes sur une réseau local, cela ne devrait pas être nécessaire.

#server.rmi.ssl.disable=false   //original

server.rmi.ssl.disable=true     //editada

9. Modifier le Service JMeter - Controleur #

Modifier le fichier jmeter-server, ce fichier contient la configuration du service JMeter pour un mode hôte ou serveur distant, c’est-à-dire nous devons configurer l’adresse IP interne du node afin qu’il puisse recevoir les requêtes de la master ou du controleur.

#RMI_HOST_DEF=-Djava.rmi.server.hostname=xxx.xxx.xxx.xxx   //original

RMI_HOST_DEF=-Djava.rmi.server.hostname=10.223.2.71     //editada

10.- Lancer le service JMeter - Controleur #

Lancez le service jmeter-server, ce service doit être exécuté pour que la machine puisse recevoir les commandes du maître. Je recommande d’utiliser nohup et de l’exécuter en arrière-plan avec &. Si vous perdez la connexion à la machine via SSH, mais que le service continue à fonctionner, quelque chose comme ceci :

nohup ./jmeter-server &
tail -f nohup.out

À la fin, je recommande d’examiner le fichier de sortie du session par SSH avec la commande tail.

11. - Exécution - Controleur #

Une fois que les nœuds sont configurés et en écoute, ils seront visibles pour le maître ou la contrôleur. Dans cet exemple, utilisez un script avec une charge minimale, juste 10 threads. Il faut noter que chaque générateur a 10 threads, ce qui entraîne l’exécution concurrente de 40 threads.

nodes

12. Vérification #

Vérifiez que les nœuds reçoivent la communication du maître et exécutent le script.

J’espère qu’ils ont réussi à reproduire cette scénario. Si non, vérifiez que tous les nœuds et le maître sont dans la même régie. Dans mon exemple, ils se trouvent sur la régie 10.223.2.0/24. Si vous utilisez AWS ou Azure, assurez-vous qu’ils sont dans la même sous-régie et VPC. Je posterai bientôt comment on peut voir ces résultats dans Grafana.

Pour conclure, je vous laisse avec l’exécution à partir de la ligne de commande.

jmeter.bat -n -t script.jmx -R 10.223.2.71,10.223.2.78,10.223.2.63,10.223.2.58

Conclusion #

Ce fonctionne bien sur Azure et AWS, les deux leaders de la fourniture Cloud IaaS en cloud, je n’ai pas testé cela sur Google mais je l’imaginais aussi travailler. Comme vous pouvez le voir ici, nous continuons avec des tâches manuelles qui nécessitent une évaluation basée sur l’analyse coût-bénéfice car ces tâches peuvent prendre du temps pour améliorer les compétences et surtout faiblir pour voir les puits potentiels où nous pourrions être bloqués. Ne vous inquiétez pas de nous contacter si vous avez besoin d’aide.