I. Introduction▲
Maintenant que nous savons comment créer des plans de tests de charge réalistes, regardons comment le faire avec l'outil JMeter.
Nous allons nous concentrer sur le test d'une application web.
II. Présentation de JMeter▲
Apache JMeter est un outil gratuit de test de charges permettant :
- de tester les performances d'une application en simulant des utilisateurs ;
- d'enregistrer les temps de réponse.
Pour cela il peut utiliser différents protocoles (HTTP, SOAP, LDAP, FTP...) afin de tester différents types d'applications (base de données, Webservice, application Web...).
Dans le cas des applications Web, JMeter possède un élément Proxy permettant d'enregistrer automatiquement le scénario afin de gagner du temps et de permettre son utilisation à un large public.
Tout cela en fait un outil assez complet.
Pour ceux qui sont habitués à des outils commerciaux (HP Mercury LoadRunner, MicroFocus SilkPerformer ou Neotys Neoload), JMeter demande un peu plus d'efforts et surtout le reporting et le monitoring y sont quasiment absents.
III. Fonctionnement de JMeter▲
Lorsqu'on lance JMeter, on se retrouve avec cet écran.
On remarque qu'on a deux espaces de travail : Test plan et Workbench. Sur chacun, on peut ajouter des éléments afin de construire notre plan de test.
Puis on ajoute des éléments/items qui vont composer nos scénarios.
III-A. Test plan▲
C'est l'espace de travail où on va mettre les éléments qui constituent notre plan de test.
III-B. Workbench▲
C'est un espace de travail temporaire.
Attention il n'est pas sauvegardé.
III-C. Description des éléments JMeter▲
Voilà une liste non exhaustive des éléments JMeter.
La liste complète des éléments se trouve sur http://jakarta.apache.org/jmeter/usermanual/component_reference.html
III-C-1. Thread group▲
C'est l'élément de base pour un scénario.
C'est ici qu'on configurera le nombre d'utilisateurs et d'itérations et la durée du ramp up (durée de montée en charge).
Depuis la version 2.5 de JMeter il existe 3 types de Thread Group.
Le "Thread Group" qui est le groupe d'unités "normal".
Le "setUp Thread Group" qui est lancé une seule fois au début d'un tir avant les "Thread Group".
Le "tearDownThread Group" qui est lancé une seule fois mais à la fin d'un tir apès les "Thread Group".
III-C-2. Sampler▲
Permet de définir le type de requête échangé avec le serveur (HTTP, FTP, JDBC...) et de les émettre.
III-C-3. Listeners▲
Permet de récupérer et d'afficher les résultats des tests (par exemple : fichiers, graphes).
III-C-4. Logic controller▲
Permet de choisir l'ordre d'exécution des Samplers (par exemple : aléatoire, boucle, conditionnel).
III-C-5. Config Element▲
Paramétrage des propriétés par défaut pour les requêtes HTTP, requêtes FTP, requêtes LDAP...
Il permet aussi de définir des variables et des jeux de données.
III-C-6. Post Processeurs▲
Permet d'effectuer des traitements après l'exécution d'une requête (ou plusieurs).
En particulier on peut utiliser pour extraire des données des résultats, des expressions régulières avec le « Regular Expression Extractor » qui utilise la syntaxe de Apache Jakarta ORO.
III-C-7. Préprocesseurs▲
Permet d'effectuer des prétraitements avant la requête, utile pour la préparation de données.
III-C-8. Assertions▲
Permet de contrôler les réponses du serveur (par exemple : temps de réponse, la réponse contient-elle une chaîne de caractères, taille, XML valide).
III-C-9. Timers▲
Permet d'ajouter des temps de pause entre chaque action (par exemple : temps constant, temps aléatoire).
Il faut faire attention à :
- ils doivent être placés en tant qu'enfant d'une requête pour que la pause soit exécutée avant l'exécution de la requête ;
- s'ils sont au niveau du Thread Group, ils s'appliqueront pour chaque requête.
Plus d'informations sur
III-C-10. Test Fragment▲
Depuis la version 2.5 de JMeter on a un nouvelle élément appelé "Test Fragment" qui permet de ne pas exécuter ses éléments fils par JMeter.
III-C-11. Plugin JMeter▲
Afin de ne pas être limité par l'installation de base de JMeter, nous pouvons utiliser les plugins qui se trouvent à l'adresse http://code.google.com/p/jmeter-plugins/.
Cela permettra aussi à ceux qui sont habitués à HP Loadrunner de s'y retrouver plus facilement.
III-C-11-a. PerfMon▲
Il est important de superviser les serveurs cibles et les injecteurs. Pour cela on peut utiliser le plugin PerfMon.
Ce plugin permet de superviser :
- l'utilisation du CPU ;
- l'utilisation de la mémoire ;
- l'utilisation du swap ;
- le nombre d'accès disque ;
- l'activité du réseau.
III-C-11-b. Stepping Thread Group▲
Permet d'affiner la configuration du ramp up à la manière de HP Loadrunner.
Plus d'informations sur http://code.google.com/p/jmeter-plugins/wiki/SteppingThreadGroup
III-C-11-c. Flexible File Writer▲
Permet de mieux paramétrer le fichier CSV de sortie avec les résultats de JMeter.
Plus d'informations sur http://code.google.com/p/jmeter-plugins/wiki/FlexibleFileWriter
III-D. Ordre d'exécution des éléments▲
Il faut faire attention à l'ordre d'exécution.
Plus d'informations sur http://jakarta.apache.org/jmeter/usermanual/test_plan.html#executionorder
IV. Processus de création d'un plan de test▲
Le plus simple pour la création d'un test avec JMeter est la façon décrite ci-dessous.
IV-A. Création des scénarios▲
Dans un premier temps, il faut créer les scénarios.
IV-A-1. Définition du scénario▲
Pour plus d'informations ici.
IV-A-2. Enregistrer/scripter▲
La méthode la plus simple pour obtenir un script est d'utiliser le proxy de JMeter pour enregistrer les requêtes effectuées entre le navigateur et le serveur.
IV-A-3. Variabiliser▲
Afin de rendre le scénario plus réaliste, ajouter des éléments non enregistrés par le proxy, éviter les effets de cache et d'ajouter la corrélation entre chaque actions/écrans, il faut utiliser un certain nombre d'éléments de JMeter (Timers, Pre processor...).
IV-A-4. Exécuter▲
Une fois cela fait, il faut vérifier que le scénario est valide. Pour cela il suffit de l'exécuter une fois avec un seul utilisateur.
IV-B. Création du plan de test▲
Une fois tous les scénarios réalisés, il faut les regrouper dans un ou plusieurs plans de test.
Par exemple
V. Conception d'un scénario de test ▲
Avant de commencer tête baissée à scripter les scénarios il est important de prendre son temps afin de bien les choisir. En effet en fonction des scénarios de test, on peut obtenir de mauvaises performances avec n'importe quelle application en simulant un usage irréaliste ou au contraire avoir des performances acceptables. De même on peut se retrouver avec énormément de tests afin d'être le plus réaliste possible et donc afin de limiter ce problème, pensez à la loi de Pareto afin de faire le tri.
Plus d'informations sur https://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/
V-A. Structure du scénario▲
Afin de faciliter la lecture des résultats et du scénario, il est conseillé de structurer ses scénarios.
Voilà une des solutions possibles.
V-A-1. Paramétrage des propriétés par défaut▲
Dans un premier temps on va ajouter des éléments « Config Element » afin de définir un certain nombre de propriétés par défaut.
V-A-1-a. Configuration du serveur cible▲
Pour variabiliser le nom du serveur web, son port... il suffit d'ajouter un élément « HTTP Request Default » et de mettre les bonnes valeurs.
Le mettre en fils de « Test plan » ou « Thread Group » pour qu'il s'applique à l'ensemble des requêtes.
Cela permet de changer facilement le serveur qu'on teste (passage d'un serveur de développement à un serveur de test).
Une option permettant de récupérer en parallèle les ressources associées à une page (script, css, images..) afin de mieux simuler les navigateurs actuels est apparu dans la version 2.5 de JMeter.
V-A-1-b. Gestion des cookies▲
De même en ajoutant l'élément « HTTP Cookie Manager », on activera la gestion des cookies.
Ne pas oublier de :
- cocher « Nettoyer les cookies à chaque itération » afin d'effacer les cookies entre chaque itération ;
- positionner Cookie Policy à compatibility pour la majorité des cas ;
- le mettre en fils de « Test plan » ou « Thread Group » pour qu'il s'applique à l'ensemble des requêtes.
V-A-1-c. Gestion du cache▲
De même en ajoutant l'élément « HTTP Cache Manager », on activera la gestion du cache afin de simuler le comportement d'un navigateur Web en matière de cache.
V-A-1-d. Gestion des en-têtes HTTP▲
Afin de paramétrer les en-têtes HTTP des requêtes envoyées, on peut ajouter un « HTTP Header Manager »
Cela permet par exemple de simuler un navigateur particulier en paramétrant le User-Agent.
Par exemple pour IE.
Pour Firefox.
Afin d'aider à trouver les bons paramètres et leurs valeurs, on peut utiliser le proxy de la manière suivante.
Activer « capture HTTP header » dans le « HTTP Proxy Server ».
Lors de l'enregistrement, on se retrouvera avec les informations nécessaires.
V-A-2. Découper en action▲
Dans un premier temps nous allons découper le scénario en transactions/actions à l'aide de « Transaction controller »
Notre scénario ressemblera à :
Thread group
Transaction controller 1
HTTP Request 1
HTTP Request 2
...
HTTP Request N
Transaction controller 2
HTTP Request 1
HTTP Request 2
...
HTTP Request N
...
Transaction controller N
HTTP Request 1
HTTP Request 2
...
HTTP Request N
Cela nous permettra d'avoir des KPI pour chaque transaction définie et ainsi faciliter la lecture des résultats.
V-A-3. Temps de réflexion▲
Afin d'être le plus réaliste possible, on va utiliser un temps variable.
Plus d'informations sur https://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/#LV-D
On peut capturer le temps de réflexion de l'utilisateur lors de l'enregistrement du script.
Pour cela il faut ajouter un élément « Uniform Random Timer » au « HTTP Proxy Server ».
Puis dans le champ « Constant Delay Offset » mettre ${T}.
A la fin de l'enregistrement, on peut voir que des éléments « Uniform Random Timer » ont été créés avec la bonne valeur.
V-A-4. Pacing▲
Plus d'information sur comment fixer la durée de répétition d'une requête sur
Ou de manière native.
V-B. Création du scénario▲
Maintenant que nous avons tous les éléments, on peut passer à l'utilisation de l'enregistreur de requêtes par le proxy pour enregistrer le scénario.
Il faut faire attention au fait que le proxy va enregistrer toutes les communications sortantes/entrantes du navigateur Web et que donc il est important de désactiver tous les plugins/... afin de ne pas enregistrer de requêtes parasites.
V-B-1. Utilisation de l'enregistreur de requêtes▲
Pour cela, il faut commencer par ajouter l'élément « HTTP Proxy Server »
Clic droit sur Workbench et Add -> Non Test Elements -> HTTP Proxy Server
Sur cet écran il faut bien noter les paramètres du proxy car on les utilisera dans la suite pour configurer notre navigateur Web pour l'enregistrement du scénario.
Cocher le paramètre Add Assertions si on veut générer un élément Asssertions automatiquement.
Maintenant on va créer pour chaque action du scénario un « Transaction Controller » (on va prendre comme exemple, la recherche d'un mot-clé sur Google).
Clic droit sur HTTP Proxy Server et Add -> Logic Controller -> Transaction Controller
Les renommer.
Modifier dans « HTTP Proxy Server » l'option « Target Controller » pour qu'elle pointe sur « Transaction Controller » nommé Accueil.
Voila on est prêt à enregistrer le scénario, pour cela il faut :
- démarrer le proxy (bouton start dans l'élément HTTP Proxy Server) ;
- configurer votre navigateur web pour qu'il utilise ce proxy (on peut utiliser le plugin foxyproxy pour Firefox) ;
- configurer votre navigateur web pour qu'il n'utilise pas son cache (pensez à le vider avant) ;
- reproduire le scénario à l'aide du navigateur web ;
- arrêter le proxy une fois la capture du scénario fini.
Ne pas oublier de faire pointer le navigateur sur le proxy.
Par exemple sous IE.
Comme on peut le voir dans JMeter, de nouveaux sous-items sont apparus.
V-C. Variabilisation des données▲
Pour rendre le scénario plus réaliste et faire attention à la gestion du cache, il faut variabiliser un certain nombre de choses comme :
- l'identifiant et le mot de passe des utilisateurs ;
- les entrées utilisateurs dans les formulaires ;
- la sélection d'un lien ;
- etc.
Plus d'informations sur https://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/#LV-A, https://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/#LV-B et http://blog.milamberspace.net/index.php/jmeter-pages/jmeter-variabilisation-de-donnees
V-C-1. Variable d'un fichier CVS▲
Un choix simple et pertinent est d'utiliser un fichier CSV en entrée à l'aide de l'élément « Config Element->CSV Data Set Config ».
Les variables récupérées pourront être utilisées dans le reste du plan de test en utilisant la syntaxe suivante ${nom de la variable}
Par exemple pour une recherche Google.
Il est possible d'utiliser Benerator pour générer ce fichier CSV.
V-C-2. Expressions régulières▲
L'utilisation des expressions régulières nous permettra de corréler des actions/écran entre eux.
Par exemple pour récupérer la session id d'un utilisateur, choisir un objet dans une liste...
Plus d'informations sur http://blog.milamberspace.net/index.php/2009/12/31/quelques-cas-dutilisation-de-lextracteur-dexpression-reguliere-dans-jmeter-554.html.
V-D. Ajout des points de contrôle▲
Afin de vérifier la réponse du serveur à la requête envoyée, il peut être utile d'ajouter des Assertions (au moins pendant la phase de création des scénarios).
Afin d'avoir un élément Assertion automatiquement créé pour chaque action lors de l'enregistrement du scénario, on peut cocher le paramètre « Add Assertions » dans l'élément « HTTP Proxy Server ».
Puis il suffit de compléter avec le test voulu.
V-E. Test de fichiers téléchargés▲
Il est possible de tester les fichiers téléchargés à l'aide d'API Java.
Pour les PDF il y a PDFBox : http://theworkaholic.blogspot.com/2010/03/asserting-pdfs.html
Pour les fichiers Microsoft Office il y a Apache POI : http://theworkaholic.blogspot.com/2010/03/asserting-ms-office-formats.html
V-F. Débogage▲
Afin de faciliter le débogage du script, on peut utiliser un « View Results Tree ».
Pour cela, clic droit sur Workbench et Add -> Listener -> View Results Tree
Ce qui nous permettra d'avoir dans l'onglet « Sampler Result » et « Response data », la réponse du serveur.
V-G. Simulation de plusieurs IP▲
Lors de certain tests, par exemple avec des Load Balancer/repartiteurs de charges, il peut être utile que les actions simulés par JMeter proviennent d'adresses IP différentes. Plus d'informations sur le blog de milamberspace
VI. Création du plan de test▲
Maintenant que nous avons un scénario de prêt, nous pouvons créer un plan de test.
Pour cela il faut ajouter dans « Test Plan », un « Thread Group ».
Clic droit sur Test Plan -> Add -> Thread Group
Puis il faut configurer le nombre d'utilisateurs et d'itérations et la durée du ramp up.
Faire de même avec les autres scénarios qui font partie du plan de test.
VII. Exécution du test▲
Maintenant que nous avons un plan de test de prêt, on peut lancer les tests.
VII-A. Baseline▲
Dans un premier temps il faut exécuter le test avec un seul utilisateur afin de :
- tester que l'application n'a pas de problèmes de performance avec seulement un utilisateur car dans ce cas, lancer la campagne de test ne sert à rien ;
- créer un baseline qui nous permettra d'avoir des KPI de référence.
VII-B. Désactivation de l'IHM▲
Pour des gros tests il faut faire attention à :
- désactiver les listeners coûteux et ne garder que Summary Listener, Graph Listener, et Spline Listener ;
- limiter le nombre de listeners ;
- désactiver le mode graphique avec l'option -non-gui ;
- générer un fichier CSV .jtl ou XML.
Plus d'informations sur http://blog.milamberspace.net/index.php/2009/02/01/jmeter-pourquoi-executer-son-test-de-charges-en-mode-non-gui-sans-interface-graphique-192.htmlet http://blog.milamberspace.net/index.php/2009/11/15/envoyer-en-ligne-de-commande-des-parametres-a-votre-scenario-jmeter-534.html et http://blog.milamberspace.net/index.php/jmeter-pages/jmeter-test-de-charges-a-distance-distributed-testing.
Pour suivre ce qui se passe lorsqu'on est en mode non-gui.
VII-C. Test de charge distribué▲
Si un seul injecteur ne suffit pas, faire un test de charge distribué (remote testing) sur plusieurs injecteurs afin de répartir la charge de test.
Plus d'information sur http://jakarta.apache.org/jmeter/usermanual/remote-test.html
VIII. Lire les résultats▲
Comme vous pouvez le constater, la partie reporting de JMeter n'est pas ce qui se fait de mieux.
La méthode la plus simple est de sauvegarder les résultats en CSV afin de les traiter avec un autre outil (Excel, outils de statistiques, outils BI...).
Par exemple avec OpenOffice.org, Access.
Pour la sauvegarde des résultats dans un fichier CSV, on peut utiliser le plugin JMeter "Flexible File Writer"
IX. Exemples de scripts JMeter▲
IX-A. Scripts pour l'application PlantsByWebSphere livrée avec IBM WebSphere 8▲
X. Conclusion▲
Comme on a pu le voir, JMeter permet d'appliquer les conseils donnés dans mon précédent article. Maintenant que nous connaissons la théorie et la pratique avec JMeter, nous verrons dans un prochain article un cas concret d'utilisation de JMeter.
XI. Remerciements▲
Merci à Milamber pour sa relecture et son aide.
Merci à ClaudeLELOUP pour sa correction orthographique.