Si vous avez un site de commerce électronique (ou n’importe quel site d’ailleurs), il n’est pas rare que vous vous attendiez à un niveau de trafic plus élevé certains jours, comme le Black Friday, par exemple. Dans de tels moments, nous devons passer nos tests de charge au niveau supérieur et simuler un plus grand nombre d’utilisateurs simultanés. Si nous exécutons nos tests de charge localement avec Apache JMeter™, le nombre d’utilisateurs que vous pouvez exécuter est limité, même si votre ordinateur dispose de suffisamment de CPU et de mémoire.
Comment créer un scénario avec plus de 800 utilisateurs simultanés utilisant JMeter ? L’une des réponses consiste à exécuter JMeter en mode distribué. Pour ceux d’entre vous qui n’en ont jamais entendu parler, voici une brève explication.
Lorsque nous parlons de distribuer JMeter, nous nous référons à une architecture Maître-esclave où JMeter utilise Java RMI pour interagir avec des objets dans un réseau distribué. Vous pouvez le voir dans l’image ci-dessous.
Les tests distribués permettent d’avoir un JMeter local (maître) qui gère l’exécution du test, ainsi que plusieurs instances JMeter distantes (esclaves) qui enverront la requête à notre serveur cible.
Mais avant de pouvoir exécuter JMeter de manière distribuée, vous devez effectuer quelques étapes simples.
Tout d’abord, nous devons avoir plusieurs ordinateurs.
Ensuite, nous devons faire fonctionner le serveur JMeter sur chaque système esclave que nous avons. Pour cela, nous devons exécuter le serveur jmeter.bat (serveur jmeter pour les utilisateurs Unix) qui se trouve dans le jmeter/bin. Une fois que nous l’exécutons, nous devrions voir quelque chose comme ça:
Ensuite, par le même chemin, mais dans le système maître, localisez le jmeter.propriétés fil. Modifiez ce fichier et ajoutez les adresses IP de tous les systèmes esclaves qui doivent être impliqués dans la propriété remote_hosts. Assurez-vous que les systèmes maître et esclave sont situés dans le même sous-réseau.
Il est très important de se rappeler que toutes les valeurs doivent être séparées par des virgules (dans cet exemple, nous utilisons un seul système esclave, juste pour rester simple).
Une fois toutes ces étapes accomplies, nous pouvons démarrer JMeter et exécuter les tests dont nous avons besoin. Dans ce cas, nous allons exécuter JMeter en utilisant le mode GUI, afin que nous puissions avoir une meilleure idée de son fonctionnement. Cependant, le mode sans interface graphique est fortement recommandé à des fins de test.
Le nombre d’utilisateurs, la montée en puissance et les itérations doivent être configurés dans le groupe de threads des systèmes maîtres comme d’habitude. Lors de l’exécution du test, ces conditions seront répliquées sur chaque système esclave.
Après avoir démarré JMeter et chargé notre test, nous avons deux options. L’un, configuré via le système maître, consiste à démarrer à distance Run->, puis à sélectionner le système esclave sur lequel nous voulons exécuter. Le second, également configuré via le système maître, est exécuté – > Remote Start All pour démarrer le test sur tous les systèmes esclaves disponibles.
( Comme nous avons défini un seul système esclave, il n’y a aucune différence entre les deux options dans cet exemple).
Nous avons ici un scénario simple où nous pouvons rechercher et consulter un article sur un site de commerce électronique:
Comme vous pouvez le voir, nous avons ajouté un écouteur d’arborescence de résultats de vue afin que nous puissions vérifier si le test a été exécuté correctement ou non. Lorsque nous exécutons un test à distance, nous allons pouvoir voir localement le résultat du test sur l’écouteur de l’arborescence des résultats de la vue comme je l’ai déjà mentionné, mais dans les systèmes esclaves, nous ne pouvons observer que l’heure de début et l’heure de fin du test.
Localement:
À distance:
Dans les coulisses, chaque système esclave exécute les tests de charge avec les conditions que nous avons définies dans le système maître. De cette façon, nous atteignons un nombre plus élevé d’utilisateurs simultanés, et donc une charge plus élevée sur notre serveur cible.
Par conséquent, si nous voulons vraiment répartir la charge, nous devons le faire manuellement. Par exemple: si nous voulons atteindre 10 000 utilisateurs simultanés et que nous avons 10 systèmes esclaves, notre plan de test doit avoir 1000 utilisateurs, donc nous finissons par en avoir 10 000 au total.
Une autre chose intéressante que nous pouvons faire est d’ajouter de la logique à notre test en ajoutant un contrôleur If. Le contrôleur If nous permet de choisir un flux particulier que nous voulons exécuter, en fonction du système qui exécute le test. Ao, différents systèmes esclaves exécuteraient différentes parties du test.
Par exemple, si nous ajoutons un paramètre lors de l’exécution du serveur jmeter sur les systèmes esclaves (./jmeter-server-Jparam =1) nous pouvons placer une condition comme{{__JavaScript({{param}==1)} dans le contrôleur If, afin que nous puissions exécuter des requêtes particulières en fonction du système esclave.
C’est tout! Nous avons exécuté avec succès un test sur un système distribué JMeter. Cela peut ne pas sembler très complexe car nous avons choisi d’utiliser un seul système esclave. Mais si vous devez simuler 25 000 utilisateurs simultanés, le coût de maintenance de tous ces systèmes est énorme. Il peut y avoir une solution de contournement possible pour les problèmes de maintenance et c’est de monter toute l’architecture que nous avons vue sur les conteneurs Docker (vous pouvez voir un exemple ici).
Cependant, cela ne sera toujours pas suffisant si notre objectif est d’exécuter des tests de charge périodiquement. Nous avons monté toute l’architecture distribuée sur un seul ordinateur, nous consommons donc une quantité considérable de ressources. Le concept de distribution de JMeter sur Docker a plus de sens si nous avons la possibilité d’augmenter le nombre de conteneurs à la demande, comme dans un service de cloud computing.
Une autre difficulté lors de l’exécution de JMeter en mode distribué est de savoir comment gérer les fichiers CSV lorsque vous avez paramétré des données dans vos tests. C’est parce que nous devons avoir des fichiers séparés, et si nous devons les mettre à jour, nous devons aller dans chaque système esclave et apporter les modifications.
Pour résoudre toutes ces limitations et inconvénients, nous pouvons utiliser BlazeMeter, qui nous fournit un moyen facile de gérer nos tests de charge. Tout ce que nous devons faire, téléchargez notre fichier JMX sur BlazeMeter. Nous pouvons également télécharger un fichier CSV consolidé avec toutes les données nécessaires et BlazeMeter se chargera de le fractionner, en fonction de la quantité de moteurs que nous avons définie.
Sur BlazeMeter, nous pouvons définir le nombre d’utilisateurs ou la combinaison de moteurs (systèmes esclaves) et de threads que nous voulons appliquer à nos tests. Nous pouvons également configurer des valeurs supplémentaires comme des emplacements multiples.
Résultats des tests:
C’est tout! Maintenant que vous avez vu quelques solutions pour exécuter des tests de charge à grande échelle, ma recommandation pour vous est de créer votre propre expérience et de décider quelle option vous offre les plus grands avantages.
Pour en savoir plus sur l’utilisation de JMeter, consultez notre académie JMeter gratuite.
