JMeter : Exécuter son scénario de tir de charge
Le scénario fonctionnel est donc dans JMeter, nous y avons apporté des affinages, et également personnalisé les tests d’assertion de chaque requête. Pour finir, nous avons contrôlé que l’exécution d’une passe (1 utilisateur virtuel qui exécute 1 fois le scénario) se déroule correctement.
Il nous reste à passer à la vitesse supérieure : stresser un peu plus son serveur Tomcat… Pour cela nous allons jouer sur les paramètres de l’élément Groupes d’unités.
Allez donc sur le Groupe d’unités pour ajouter les utilisateurs virtuels (disons 100), sur une période de montée en charge de 50 secondes, et chaque utilisateur virtuel va exécuter 50 fois le scénario de tir.
On relance le tir de charge (Ctrl+E, pour effacer les résultats, puis Ctrl+R, pour lancer le test).
On note que pendant l’exécution du tir de charge, en haut à droite de la fenêtre JMeter, il y a :
- Un petit carré qui est vert, ce qui signifie que le tir est en cours, quand il sera terminé, il deviendra gris
- Le premier chiffre (21) indique le nombre d’utilisateurs virtuels en train de « travailler »
- Le deuxième chiffre (100) indique le nombre d’utilisateurs virtuels prévus pour ce test de charge (la valeur du champ Nombre d’unités (utilisateurs) dans l’élément Groupes d’unités)
Voici le résultat de l’exécution de ce petit tir de charge :
Et voilà, au total, 30000 requêtes (6 fois 5000 requêtes). Chaque requête de test a été demandée 5000 fois (100 utilisateurs virtuels X 50 itérations).
Quelques explications sur les colonnes :
- Libellé : ‘Identifiant’ de l’élément (son nom)
- # Echantillons : Nombre d’exécution de l’échantillon (ou groupement d’échantillons)
- Moyenne (ms) : Moyenne de temps de réponse pour l’ensemble des requêtes d’un même élément
- Min (ms) : Valeur du temps de réponse minimum
- Max (ms) : Valeur du temps de réponse maximum
- Ecart type (ms) : Répartition des échantillons autour de la valeur moyenne
- % Erreur : Pourcentage de résultats marqué en erreur
- Débit : Bande passante exprimée en sec ou min ou heure (C’est-à-dire, combien de fois on peut avoir l’élément en 1 sec ou 1 min ou 1 heure)
- Ko/sec : Vitesse de transfert en Kilo-octets par seconde
- Moy. octets : Moyenne des octets. Indique le nombre d’octets moyenne transférés
Ceci conclut cette petite introduction aux tests de charges d’un site Web avec Apache JMeter.
Quelques remarques :
- Ceci est une petite introduction à l’utilisation de JMeter pour faire un tir de charge sur un « site Web ». C’est modeste, il faut en effet, faire plusieurs types de tests de charge pour avoir une bonne idée des performances d’un environnement (par exemple, de bande passante, de transactions/sec, de vitesse de croisière, par paliers de VU (utilisateurs virtuels), par période Normale/Pic/Normale, etc.)
- Par ailleurs, l’élément Rapport consolidé est insuffisant pour avoir un bon aperçu des performances d’une plateforme, il faut en effet regarder l’évolution des temps de réponse durant le tir, par exemple à travers un récepteur Graphique de résultats dans JMeter, ou à travers un tableau croisé dynamique (table pivot) dans OpenOffice Calc ou Microsoft Excel (ou Access). Le table pivot récupérant les données depuis le fichier d’enregistrement des résultats de JMeter (champ Ecrire les données dans un fichier). Le travail sur les données d’un résultat de test de charge sera l’un des prochains articles sur mon blog, patience donc. MAJ: L’article est fait, clic ici.
- N’allez pas mettre 10000 VU, et lancer un nouveau tir de charge… vous allez surcharger la bande passante de votre carte réseau, votre CPU, et vous aurez peut-être même un OutOfMemory de la JVM exécutant JMeter. Si vous devez simuler beaucoup d’utilisateurs, il est préférable d’utiliser plusieurs « injecteurs » (stations JMeter) qui seront pilotés par une station JMeter principale. La aussi, il faut que j’en fasse un article. MAJ: L’article est fait, clic ici.
- Pour terminer, il faut aussi que je fasse un article pour montrer comment « variabiliser » les données saisies dans les formulaires Web, histoire que le robot ne fasse pas la même transaction à chaque appel du scénario. MAJ: l’article est fait, clic ici
- Ah! et il faut aussi que je vous parle des « think time » dans un article (MAJ : Ici par exemple)… Il y a en effet une grande différence entre le comportement d’un être humain et un robot. Ce dernier exécute les requêtes les unes à la suite des autres sans délai, alors que nous (pauvres humains) mettons quelques ms/secs/min pour faire une action sur notre navigateur.
- Bon je m’arrête là. J’ai beaucoup de choses à dire sur JMeter, mais à chaque jour suffit sa peine 😉
./
Bonjour,
Je ne connait Jmeter que depuis 1 semaine et grâce à toi et Jmeter, cela nous a permis de trouver un bug récurrent sur notre appli J2EE suite à des confits entre thread.
Un grand merci,
J’aimerai même participer à tes articles, comme :
Comment organiser son script pour plus de visibilité
Trucs et astuces
Comment importer et exploiter les données sous open Office plutôt que access
cdt,
arnaud
Salut,
De rien, ravi de vous avoir aider.
Tu peux participer à la visibilité de Jmeter, notamment à travers le groupe JMeter en français :
http://groups.google.com/group/jmeter-fr
Si jamais tu as un tutorial ou des astuces, je peux aussi les publier sur ce blog avec ton « copyright ».
Merci d’avance.
A+
Milamber
Un grand merci pour ce tutorial très bien détaillé !!!!
Bonjour,
d’abord, merci pour ce super tutorial. j’ai suivi ce tutorial pour mon test (je suis débutante de JMeter). Mon scénario contient plusieurs étapes, quand je lance le test sur mon web service (tomcat sous eclipse), normalement,il passe tous les procédures pour le premier utilisatuer en tant que je redémarre le Tomcat, mais les autres utilisateurs fait que l’étape login. (j’ai ajouté le gestionaire de cookie pour gérer le session ID)
est-ce que cela vous dit quelques choses?
merci pour ton aide.
A +
soleil
Bonjour,
Merci.
Que te donnes l’arbre de résultats au niveau des requêtes des autres utilisateurs ?le login fonctionne ?
Peut-être est-ce un problème au niveau des parametres envoyés dans les pages…
A+
Bonjour,
merci de me répondre si vite, c’est très gentil.
En fin, j’ai trouvé où se trouve le pb: en fait, le version d’application que j’ai testé a un traitement supplémentaire de session ID. J’ai utilisé aussi bad boy pour l’enregistrer et je n’arrive pas de faire ‘replay’ sur ce version. (le session ID est perdu après login) En tous cas, je suis en trains de tester un ancien version et ça marche bien.
Par ailleurs, comme je teste plutôt sur une application fonctionnelle. j’ai ajouté ‘thinking time’ dans chaque étape du plan. J’ai comparé avec le résultat que j’ai pas ajouté ‘thinking time’, il n’y a pas assez de différence au niveau de temps de réponse. Je voudrais te vérifier si dans le rapport agrégé, le temps de réponse indique que le temps d’appeler l’application et non pas ajouter directement le temps que j’ai ajouté dans ‘timer’?
merci par avance
PS: je m’excuse mon français, j’espère que ma question est comprensible:)
A +
Soleil
Bonjour,
Est-ce que tu as utilisé un élément Gestionnaire de Cookies ? afin de capter le cookie utilisé par ton application.
Dans le rapport agrégé, c’est le temps cumulé (temps de réponse + think time) si tu es dans un élément Transaction Contrôleur. Pour les requêtes HTTP (celles de JMeter), c’est le temps de réponse de la requête http..
Pas de problème pour ton français, c’est très compréhensible.
A+
Milamber
Salut Milamber,
oui, j’ai ajouté ‘Gestionnaire de Cookies’. ce que m’apparaît bizarre est: j’ai ajouté 9000 milleseconde comme le temps fixé à l’étape ‘page de login’ afin que l’utilisateur peut saisir son user et pwd. Par contre, quand je récupère le résultat, j’ai eu 183 millesecondes en moyen et 4 millesecondes au minimum(j’ai simulé 400 utilisateurs). Pendant le test, j’ai bien vu que le temps est ralenti. je me suis dit que dans le tableau de rapport agrégé ou graphique agrégé, le temps de réponse est justement le temps de réponse de la requête http…
merci
A+
soleil
Bonjour,
Oui, le temps est bien le temps de réponse de la requête HTTP.
Les 9000 ms seront ajoutées si tu as un Contrôleur de Transaction, par exemple :
-Groupes d’unités
| |–Contrôleur de transaction
| |–Requête HTTP
| |–Compteur de temps fixe (9000 ms)
|–Arbre de résultats
A+
Milamber
oui, merci pour ton indice.
en fait, j’ai véirifié que dans le rapport agrégé, j’ai le temps de controleur transaction qui contient le temps de réponse de la requête HTTP et le temps fixe de toute la chaine.
merci encore une fois
A+
Soleil
Bravo… Vraiment bravo
Salut,
Merci pour ces tutos,
J’ai en ce moment un problème bloquant sans solution.
Après avoir capturé et structuré mon scénario, je lance le test mais je n’ai que ces erreurs :
java.net.SocketException: socket closed
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$6.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.net.www.protocol.http.HttpURLConnection.getChainedException(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at org.apache.jmeter.protocol.http.sampler.HTTPJavaImpl.readResponse(HTTPJavaImpl.java:263)
at org.apache.jmeter.protocol.http.sampler.HTTPJavaImpl.sample(HTTPJavaImpl.java:516)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1018)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1004)
at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:411)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:297)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.SocketException: socket closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(Unknown Source)
at java.net.URLConnection.getHeaderFieldInt(Unknown Source)
at java.net.URLConnection.getContentLength(Unknown Source)
at org.apache.jmeter.protocol.http.sampler.HTTPJavaImpl.readResponse(HTTPJavaImpl.java:232)
… 7 more
Est-ce que ça vous parle ? Est-ce du au proxy ? (je l’ai bien configuré car j’ai bien réussi à capturer le scénario depuis mon navigateur). J’ai vu qu’il était possible qu’il faille utiliser java 1.5. N’y a t’il pas une autre solution ? J’ai l’impression que mon problème est spécifique à mon environnement pourtant classique.
J’ai oublié de dire que les résultats ne s’affichent pas pendant le tir, il faut que j’arrête le tir pour obtenir ces erreurs sur chaque requête.
j’ai trouvé,
j’ai ajouté ma config de proxy dans le fichier system.properties (ce qui fonctionne)
ensuite je capture correctement mon scénario
Mais après cela, il faut que je supprime ma config du system.properties, que je redémarre JMeter et que je déclare mon proxy dans mon élément « paramètres http par defaut ». Et là ça marche…
Bon, je suis sûr qu’il y a moyen de ne pas avoir à reconfigurer à chaque fois le system.properties mais bon, j’ai déjà une solution.
Voilà le moyen de le faire en ligne de commande :
http://jakarta.apache.org/jmeter/usermanual/get-started.html#proxy_server