JMeter : Test de charge distribué (distributed testing)

JMeter permet de faire des tests de charge distribués sur plusieurs robots de tests. L’idée étant de répartir la charge de test de JMeter sur plusieurs robots de tests. Pourquoi ? Car, si on essaye de faire un tir de charge avec un très grand nombre d’unités (utilisateurs virtuels) sur une même machine JMeter, on risque de saturer la machine au niveau réseau (c’est-à-dire la bande passante), la CPU ou bien la mémoire. On peut même saturer le disque lors de l’écriture des résultats en particulier si on choisit le format XML. Tout cela pour dire que : la répartition d’un tir de charge sur plusieurs machine est une solution à ce type de test.

Voici un tutoriel qui explique la démarche.

Tout d’abord, voyons l’architecture à mettre en place : une instance de JMeter que nous appellerons le « contrôleur ». C’est à partir de ce poste que l’on contrôlera les instances de JMeter « distantes ». Ces dernières seront nommées « injecteurs ».

Schéma de test distribué JMeter

Pour réaliser un tir de charge « distribué » qui correspond à ce schéma, voici ce qu’il faut faire.

Tout d’abord au niveau du contrôleur de tir (192.168.1.10), il faut installer un JMeter (ici version 2.4-dev r922088).

Ensuite, sur le contrôleur, on édite le fichier user.properties (situé dans JMETER_HOME/bin/), on ajoute la ligne suivante à la fin :

remote_hosts=injec1,injec2

Puis enregistrer et quitter.

Afin d’avoir la correspondance nom<->IP, on modifiera le fichier hosts de la machine contrôleur (sous Linux : /etc/hosts, sous Windows : C:\Windows\System32\drivers\etc\hosts) en y ajoutant les lignes suivantes :

192.168.1.11	 injec1
192.168.1.12	 injec2

(NB. On peut se passer de la modification du fichier hosts, en mettant directement les adresses IP dans la ligne remote_hosts=192.168.1.11,192.168.1.12. Pour ma part, je préfère utiliser des noms car c’est plus simple que les adresses IP – dans ma perception des choses.)

Ensuite, lancer le JMeter de la machine Contrôleur, puis en parcourant le menu Lancer > Démarrage distant vous trouverez la liste des deux injecteurs.

JMeter démarrage distant

Passons donc du coté des injecteurs :

Pour chacun, il suffit de :

  1. Installer JMeter (il est préférable (fortement) d’avoir la même version que le contrôleur)
  2. Lancer JMeter en mode « server » avec la commande :
JMETER_HOME/bin/jmeter-server (sous Linux)
JMETER_HOME\bin\jmeter-server.bat (sous Windows)

Ce mode va démarrer une instance de JMeter qui se mettra en écoute sur le port Java RMI (1099). C’est à travers ce dernier que le contrôleur va envoyer les commandes de tirs.

(NB. Le mode serveur est un mode non-gui, c’est à dire que vous ne verrez pas l’interface graphique de JMeter.)

Revenons sur le contrôleur :

Pour lancer le tir à distance, il faut bien entendu un scénario de tir. Il n’y a pas de différence entre un fichier de scénario « mono » instance JMeter et un scénario pour un tir à distance.

Ainsi on ouvre le scénario dans le JMeter Contrôleur. Dans la partie Groupe d’unités on trouve le nombre d’unités à 5, une durée de montée en charge de 1 seconde, et un nombre d’itérations de 1000 (par utilisateur).

JMeter Groupe d'unités

Ces paramètres seront utilisés « tels quels » sur chaque injecteur. C’est à dire que si on lance le tir sur 2 injecteurs, on aura de manière cumulée : 10 unités, avec une période de montée en charge de 1 seconde et une boucle de 1000 exécutions (soit 10 000 itérations de l’échantillon HTTP Request de notre exemple avec deux injecteurs).

Dans le scénario, il y a un fichier d’enregistrement des résultats qui se chargera de récolter l’ensemble des temps de réponses des injecteur. Par exemple ici,  un élément Enregistreur de données. Ce fichier sera créé uniquement sur le Contrôleur.

Element Simple Data Writer

Le meilleur format pour ce type de tir est un fichier CSV plutôt que XML car chaque injecteur va transmettre au contrôleur ses résultats, c’est donc plus « verbeux/lourd » et nécessite de de la bande passante entre le contrôleur et ses injecteurs.

Le Contrôleur centralise donc les résultats, c’est sur ce poste que l’on trouvera donc le fichier de résultats « consolidés » après le tir, dans le répertoire et fichier configurés (ici : /tmp/remote-test.csv)

Lancement du tir

Il reste à démarrer le tir à distance. Pour lancer le tir sur tous les injecteurs en même temps, il suffit de choisir le menu Run > Remote Start All.

Et hop le tir est démarré… pas exactement, la première étape que fait JMeter, c’est de transférer le fichier JMX (script JMeter) du tir vers les injecteurs. Ce qui signifie que cela peut prendre un peu de temps si le fichier JMX de scénario est volumineux (plusieurs Mo).

On notera que pendant l’exécution du tir, le petit carré est vert, mais les indicateurs du nombre de VU sont à 0.

Jmeter Test de charge à distance

Une fois le test de charge terminé, il ne reste plus qu’à récupérer le fichier de résultats qui se trouve sur le Contrôleur. Si vous avez choisi le format CSV, vous pouvez exploiter les résultats en suivant la fin de ce tutoriel.

Quelques recommandations (importantes) :

1/ Mode ligne de commande : L’utilisation de Jmeter en mode graphique pour le contrôleur n’est pas recommandée car très consommateur de ressources (en particulier si vous utilisez un récepteur Arbre de résultats (il y aun risque d’erreur de type OutOfMemoryError sur le JMeter Contrôleur).

Le mode ligne de commande est ainsi plus adaptée car il ne consomme pas de ressource mémoire pour l’affichage des résultats. Voici la ligne à saisir (pour Linux, les options restant les mêmes pour Windows, il faut simplement adapter les chemins) :

JMETER_HOME/bin/jmeter -n -r -X -t /home/milamber/monscenario.jmx
  • Le « -n » c’est l’activation du mode texte (non graphique)
  • Le « -r » c’est le mode à distance (tous les serveurs de la ligne remote_hosts)
  • Le « -X » est une option permettant demander à JMeter (contrôleur) de stopper les instances de JMeter des injecteurs à la fin du tir. (c’est plus propre que de faire un kill du processus en fin de tir ;-))

2/ Firewall : il faut penser à désactiver les pare-feux sur le poste Contrôleur et sur les injecteurs. Sinon, soit rien va ne se lancer quand vous allez démarré le tir distribué. Ainsi dans le cas d’un firewall unidirectionnel sur le contrôleur, vous verrez le tir se lancer sur les injecteurs dans les logs, mais ensuite plus rien, car l’injecteur n’arrive pas à contacter le contrôleur pour transmettre les résultats.

3/ Logs des injecteurs : pour suivre l’avancement du tir depuis un injecteur, vous pouvez regarder le fichier JMETER_HOME/bin/jmeter-server.log. Ce dernier contiendra les lignes de démarrage des unités (les Utilisateurs Virtuels / VU) et les lignes d’arrêt.

Exemple :

2008/09/21 10:43:36 INFO  - jmeter.threads.JMeterThread: Thread Thread Group 1-10 started
2008/09/21 10:45:47 INFO  - jmeter.threads.JMeterThread: Thread Thread Group 1-1 is done
2008/09/21 10:45:47 INFO  - jmeter.engine.StandardJMeterEngine: Ending thread Thread Group 1-1

4/ Version Java / JDK : il est préférable d’avoir la même version de Java pour les injecteurs et le contrôleur. Sachant que pour JMeter version 2.3.2, le JDK 1.5 est recommandé. (Notamment à cause de l’implémentation du protocole RMI qui sert de support de communication entre les injecteurs et le contrôleur.)

5/ Injecteurs et contrôleur, Système d’exploitation : On préférera avoir le même OS pour tout le monde (pour éviter les problèmes). Néanmoins, j’ai déjà effectué des tirs de charges à distance avec un contrôleur Windows (XP ou Vista) et des injecteurs Linux (Ubuntu Server), ou bien le contraire, ceci sans problème.

6/ Format fichier de résultats : comme déjà indiqué, il est préférable de choisir le format CSV. On notera également que JMeter propose d’ajouter le nom d’hôte (d’injecteur) pour chaque requête au niveau de la ligne CSV. Ce qui est pratique pour vérifier que tous les injecteurs ont bien fonctionné durant le tir.

Exemple de résultats CSV :

timeStamp;elapsed;label;responseCode;threadName;success;failureMessage;bytes;Latency;Hostname
"2008-09-21;10:56:34";34;01 /servlets-examples/index.html;200;Thread Group 1-1;true;;5343;10;injec1
[...]
"2008-09-21;10:57:15";8;01 /servlets-examples/index.html;200;Thread Group 1-10;true;;5343;8;injec2
"2008-09-21;10:57:14";3;01 /servlets-examples/index.html;200;Thread Group 1-10;true;;5343;2;injec1
"2008-09-21;10:57:14";3;03 /servlets-examples/index.html;304;Thread Group 1-3;true;;0;0;injec1
"2008-09-21;10:57:15";7;04 /servlets-examples/servlet/SessionExample;200;Thread Group 1-3;true;;1270;7;injec2
"2008-09-21;10:57:14";6;03 /servlets-examples/index.html;304;Thread Group 1-1;true;;0;0;injec1

7/ Nombre d’injecteurs : Il n’y a pas de limite au nombre d’injecteurs que peut gérer le contrôleur dans la théorie. Dans la pratique, c’est la performance du contrôleur ainsi que la bande passante disponible entre lui et les différents injecteurs, qui le limite.

./

[Ajout 26/03/2009] : un billet sur la mise en place d’un test distribué avec des injecteurs ayant deux cartes réseaux.

[Mise à jour 19/04/2010] : Utilisation de captures de JMeter en français (version 2.4-dev), différentes corrections sur le style d’écriture et corrections de fautes d’orthographe

24 réflexions au sujet de « JMeter : Test de charge distribué (distributed testing) »

  1. Petit retour d’expérience : ceci ne fonctionne pas correctement quand on a plusieurs cartes réseau. C’était le cas sur mon contrôleur de tir. Tous les injecteurs fonctionnent mais on a aucun retour sur le contrôleur. J’ai été obligé de désactiver toutes les cartes réseau sauf une. J’imagine que JMeter prend la première adresse IP qu’il trouve et que les injecteurs n’arrivent pas à répondre sur cette adresse puisque la première n’est pas la bonne dans mon cas.

    En tous cas bravo et merci pour ce site qui m’a beaucoup aidé.

  2. Merci pour ce retour d’expérience.
    On peut peut-être corriger (ou faire corriger) ce problème en déclarant un bug dans le bugzilla du projet.
    (je pense qu’il s’agit d’un problème au niveau Java RMI car c’est la chose sous-jacente utilisé par Jmeter pour la communication entre le contrôleur et les injecteurs)

  3. Avant tout, un grand merci pour ce tutoriel en français!

    J’ai une question concernant le fichier de resultat au format .CSV. Prenons le cas d’un fichier nomme ‘resultats.csv’.
    Si je fais un test de plusieurs heures, ce fichier de resultats peut prendre une taille tres importante. Existe-t-il un moyen de dire a JMeter que le fichier de resultat quand il atteint la taille de 20Mo par exemple, il me renombre en resultats1.csv et continue et comme ça ainsi de suite. De cette maniere, j’ai une seri de fichiers de resultats (resultats1.csv, resultats2.csv, resultats3.csv, resultats4.csv, …) de 20Mo qui sont plus exploitables pour moi et pour Excel aussi.

    Je ne sais pas si je me suis bien fait comprendre mais c’est un peu comme la configuration du log4j.properties ou tu peux definir une rotation des fichiers et la taille max des fichiers de log et ensuite le log4j le gere tout seul.

    A+
    Phil.

  4. Bonjour,

    De rien, avec plaisir.

    La rotation des fichiers de résultats n’est pas possible (implémentée) avec JMeter.
    Pour compléter ma réponse, je dirais que cela ne va rien t’apporter d’avoir des fichiers de plus petites tailles.
    En effet :
    1/ si jamais tu gardes des fichiers de grande taille (genre 500Mo), tu peux toujours les découper (manuellement avec ultraedit ou autres, ou bien avec des commandes unix/linux comme tail/head/awk si tu connais)
    2/ plus important : Excel est limité à environ 32000 lignes/points pour la génération d’un graphique (et 65535 pour une feuille), donc si tu as un fichier de résultat avec plus de 32000 lignes, tu ne pourras pas vraiment faire des graphs.

    Pour contrer ce type de problème, tu peux utiliser d’autres outils pour générer des graphiques et qui sont plus puissants car ils peuvent accepter des fichiers de 500 Mo de données, je pense à GnuPlot. cf un article sur mon blog
    http://blog.milamberspace.net/index.php/2008/10/26/faire-des-graphiques-de-resultats-jmeter-avec-gnuplot-100.html

    Donne plus de détails sur les objectifs d’avoir plusieurs fichiers, si jamais j’ai mal compris.

    A+

  5. Milamber, merci pour la reponse rapide!

    1. La raison d’avoir des fichiers de plus petites tailles est tout simplement pour un soucis de comodite, c’est-a-dire, ne pas a avoir a utiliser quelconque utilitaire pour decouper un fichier de 500Mo. Si JMeter le faisait en modifiant le fichier jmeter.properties, c’etait tout benef! Mais comme c’est pas le cas… je ferai donc le decoupage moi-meme.

    2. Et comme tu dis, je voulais les decouper automatiquement pour pouvoir les lire plus facilement dans un fichier Excel.

    3. Concernant GnuPlot, j’avais deja lu ton article dessus et j’ai d’ailleurs installe et teste selon ton exemple et ça fonctionne tres bien mais j’ai du zappe que GnuPlot supportait les gros fichiers…

    En supposant que je ne me preoccupe pas de la taille du fichier, sais-tu si JMeter, au moment d’ecrire les resultats dans un fichier de 1 Go, a un impact important sur son comportement?

    J’ai un scenario avec 25 utilisateurs et en 1h, mon fichier de resultats atteint la taille de 50Mo. Si j’augmente le scenario a 100 utilisateurs, la taille du fichiers pourrait atteindre les 200Mo et si au lieu de 1h, je fais 5h, le fichier peut atteindre le Go…

    Je devrais ensuite tester a 1000 utilistateurs et la ça m’inquiete… 🙁

    A+
    Phil.

  6. Bonjour,

    Normalement l’écriture dans un gros fichier n’a pas d’impact sur le comportement de JMeter. En revanche, on peut penser que si il y a un gros fichier, il y a un « gros » test de charges, donc le JMeter doit être « bien » occupé à gérer le tir et la réception des résultats.
    Par rapport à ton plan de test, j’espère donc que tu as prévu un lancement de tir en mode non-gui (pas d’interface graphique, car sinon, JMeter demandera trop de ressources (CPU et mémoire) pour le tir et risque clairement de modifier (rallonger les temps de réponses) le tir.

    Tu peux aussi penser à modifier les données enregistrées dans le fichier CSV, en limitant au maximum (par exemple, ne pas mettre la date du jour (juste l’heure, le nom de l’injecteur, le code de retour http, le message d’assertion, la latence, etc).
    Pour les erreurs d’assertion, tu peux mettre un listener d’assertion et configurer un fichier d’écriture pour avoir un fichier à part avec seulement les erreurs d’assertion pour ton tir.

    Pour revenir sur GnuPlot, pour ma part j’ai déjà générer un graphique avec 710 000 lignes avec succès. (et je suppose que l’on peut faire plus…)

    A+

  7. Un grand merci pour ces conseils.

    En relisant, tes articles, j’ai donc lance les premiers tests (que je lance toujours en mode non-gui) en ne tenant pas compte des images ni des css et ni les js pour m’occuper uniquement des temps de reponses au niveau des pages. Je viens de le faire et on sent tout de suite la difference.

    Et derniere chose, je viens de lire qu’Excel 2007 supporte beaucoup plus de lignes qu’Excel 2003. Le mythe d’Excel limité a 65.536 lignes, c’est fini. On peut donc maintenant avoir des fichiers de 1.048.576 lignes avec Excel 2007.

    Voila!

    Merci Milamber!

    A+
    Phil.

  8. Content de t’avoir aider, merci aussi à toi pour l’info sur Excel 2007 (mais il faudrait voir combien de points possible pour un graphique).
    Bon courage

  9. Pour le graphique, ça n’a, helas, pas change. Que ce soit Excel 2003 ou Excel 2007, ça reste limite a 32000 donnees. 🙁
    C’est pour ça que, comme toi, j’opte pour la solution GnuPlot.

    Merci Milamber,

    A+
    Phil.

  10. Ping : MilamberSpace » Archive du blog » JMeter : faire un test distribué avec des injecteurs à deux cartes réseaux

  11. Bonjour,

    j’aurais souhaité savoir si quelqu’un a déjà rencontré le problème suivant pour des tirs en remote :

    J’ai 3 requêtes dans le plan de test que je tire depuis 2 serveurs distant.

    Tout s’effectue en ligne de commande avec un SimpleDataWriter mode CSV.

    Au lieu d’obtenir 6 lignes dans mon fichier de logs (correspondant au 3 requêtes pour chacun des serveurs) je n’en obtient que 5.

    J’ai effectué des dizaines de tests sans succès. En revanche, lorsque je tir depuis le GUI avec un summary report, je visualise bien mes 6 requêtes…

    version utilisée :2.3.2

    merci.

  13. Bonjour,

    Je viens de suivre ce tuto pour configurer mon test de charge et merci, il m’a beaucoup aidé.

    Cépendant, j’ai un petit soucis, lorsque je lance le « JMETER_HOME/bin/jmeter-server » sur les injecteurs puis que je fais un démarrage distant sur mes injecteurs, tous les injecteurs me répondent :

    Starting the test on host 10.0.1.32 @ Thu Oct 22 16:31:11 CEST 2009 (1256221871310)
    Finished the test on host 10.0.1.32 @ Thu Oct 22 16:31:12 CEST 2009 (1256221872234)
    Starting the test on host 10.0.1.32 @ Thu Oct 22 16:31:24 CEST 2009 (1256221884932)
    Finished the test on host 10.0.1.32 @ Thu Oct 22 16:31:25 CEST 2009 (1256221885704)

    Comme on peut le voir, j’arrive à faire un démarrage distant sur mes injecteurs, mais il se termine une seconde après…

    Qq1 aurait une solution à ce problème ?

    Je précise que tout mes injecteurs, ainsi que mon serveur Jmeter tournent sous Ubuntu 8.04 LTS.

    Merci d’avance.

  14. Bonjour,

    Que dis le fichier Jmeter_hom/bin/jmeter-server.log ?

    As-tu bien configurer un nombre d’unités (VU), un nombre de rotation ?

    A+
    Milamber

  15. Je suis désolé mais je débute avec Jmeter…

    Où se trouve le fichier pour configurer un nombre d’unités et un nombre de rotation ?

    Pour ce qui est du Jmeter_hom/bin/jmeter-server.log, j’ai refait un test et ça me donne :

    2009/10/23 09:29:10 INFO – jmeter.protocol.http.sampler.HTTPSamplerBase: Cannot find .className property for htmlParser, using default
    2009/10/23 09:29:10 INFO – jmeter.protocol.http.sampler.HTTPSamplerBase: Parser for text/html is
    2009/10/23 09:29:10 INFO – jmeter.protocol.http.sampler.HTTPSamplerBase: Parser for application/xhtml+xml is
    2009/10/23 09:29:10 INFO – jmeter.protocol.http.sampler.HTTPSamplerBase: Parser for application/xml is
    2009/10/23 09:29:10 INFO – jmeter.protocol.http.sampler.HTTPSamplerBase: Parser for text/xml is
    2009/10/23 09:29:10 INFO – jmeter.protocol.http.sampler.HTTPSamplerBase: Parser for text/vnd.wap.wml is org.apache.jmeter.protocol.http.parser.RegexpHTMLParser
    2009/10/23 09:29:10 INFO – jmeter.protocol.http.sampler.HTTPSampler: Maximum connection retries = 10
    2009/10/23 09:29:10 INFO – jmeter.protocol.http.sampler.HTTPSampler: Connection and read timeouts are available on this JVM
    2009/10/23 09:29:10 INFO – jmeter.engine.RemoteJMeterEngineImpl: Creating JMeter engine on host 10.0.1.32
    2009/10/23 09:29:10 INFO – jmeter.engine.StandardJMeterEngine: Listeners will be started after enabling running version
    2009/10/23 09:29:10 INFO – jmeter.engine.StandardJMeterEngine: To revert to the earlier behaviour, define jmeterengine.startlistenerslater=false
    2009/10/23 09:29:10 INFO – jmeter.engine.RemoteJMeterEngineImpl: running test
    2009/10/23 09:29:11 INFO – jmeter.engine.StandardJMeterEngine: Running the test!
    2009/10/23 09:29:11 INFO – jmeter.engine.util.CompoundVariable: Note: Function class names must contain the string: ‘.functions.’
    2009/10/23 09:29:11 INFO – jmeter.engine.util.CompoundVariable: Note: Function class names must not contain the string: ‘.gui.’
    2009/10/23 09:29:11 INFO – jmeter.samplers.RemoteListenerWrapper: Test Started on 10.0.1.32
    2009/10/23 09:29:11 ERROR – jmeter.samplers.RemoteListenerWrapper: testStarted(host) java.rmi.ConnectException: Connection refused to host: 127.0.1.1; nested exception is:
    java.net.ConnectException: Connection refused
    at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:601)
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198)
    at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184)
    at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:110)
    at org.apache.jmeter.samplers.RemoteSampleListenerImpl_Stub.testStarted(Unknown Source)
    at org.apache.jmeter.samplers.RemoteListenerWrapper.testStarted(RemoteListenerWrapper.java:75)
    at org.apache.jmeter.engine.StandardJMeterEngine.notifyTestListenersOfStart(StandardJMeterEngine.java:277)
    at org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:413)
    at java.lang.Thread.run(Thread.java:619)
    Caused by: java.net.ConnectException: Connection refused
    at java.net.PlainSocketImpl.socketConnect(Native Method)
    at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
    at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
    at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
    at java.net.Socket.connect(Socket.java:525)
    at java.net.Socket.connect(Socket.java:475)
    at java.net.Socket.(Socket.java:372)
    at java.net.Socket.(Socket.java:186)
    at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22)
    at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128)
    at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595)
    2009/10/23 09:29:11 INFO – jmeter.threads.JMeterThread: Thread finished: 5000m 1-1
    2009/10/23 09:29:11 INFO – jmeter.engine.StandardJMeterEngine: Ending thread 5000m 1-1
    2009/10/23 09:29:11 INFO – jmeter.engine.StandardJMeterEngine: Stopping test
    2009/10/23 09:29:11 INFO – jmeter.engine.StandardJMeterEngine: Notifying test listeners of end of test
    2009/10/23 09:29:11 INFO – jmeter.services.FileServer: Default base=/home/glabadmin/jakarta-jmeter-2.3.4/bin
    2009/10/23 09:29:11 INFO – jmeter.samplers.StandardSampleSender: Test Ended on 10.0.1.32
    2009/10/23 09:29:11 WARN – jmeter.samplers.StandardSampleSender: testEnded(host)java.rmi.ConnectException: Connection refused to host: 127.0.1.1; nested exception is:
    java.net.ConnectException: Connection refused
    2009/10/23 09:29:11 INFO – jmeter.samplers.StandardSampleSender: Test Ended on 10.0.1.32
    2009/10/23 09:29:11 WARN – jmeter.samplers.StandardSampleSender: testEnded(host)java.rmi.ConnectException: Connection refused to host: 127.0.1.1; nested exception is:
    java.net.ConnectException: Connection refused
    2009/10/23 09:29:11 INFO – jmeter.samplers.StandardSampleSender: Test Ended on 10.0.1.32
    2009/10/23 09:29:11 WARN – jmeter.samplers.StandardSampleSender: testEnded(host)java.rmi.ConnectException: Connection refused to host: 127.0.1.1; nested exception is:
    java.net.ConnectException: Connection refused
    2009/10/23 09:29:11 INFO – jmeter.samplers.StandardSampleSender: Test Ended on 10.0.1.32
    2009/10/23 09:29:11 WARN – jmeter.samplers.StandardSampleSender: testEnded(host)java.rmi.ConnectException: Connection refused to host: 127.0.1.1; nested exception is:
    java.net.ConnectException: Connection refused
    2009/10/23 09:29:11 ERROR – jmeter.samplers.RemoteTestListenerWrapper: java.rmi.ConnectException: Connection refused to host: 127.0.1.1; nested exception is:
    java.net.ConnectException: Connection refused
    at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:601)
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198)
    at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184)
    at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:110)
    at org.apache.jmeter.samplers.RemoteSampleListenerImpl_Stub.testEnded(Unknown Source)
    at org.apache.jmeter.samplers.RemoteTestListenerWrapper.testEnded(RemoteTestListenerWrapper.java:74)
    at org.apache.jmeter.engine.StandardJMeterEngine.notifyTestListenersOfEnd(StandardJMeterEngine.java:291)
    at org.apache.jmeter.engine.StandardJMeterEngine.access$300(StandardJMeterEngine.java:58)
    at org.apache.jmeter.engine.StandardJMeterEngine$2.run(StandardJMeterEngine.java:327)
    Caused by: java.net.ConnectException: Connection refused
    at java.net.PlainSocketImpl.socketConnect(Native Method)
    at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
    at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
    at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
    at java.net.Socket.connect(Socket.java:525)
    at java.net.Socket.connect(Socket.java:475)
    at java.net.Socket.(Socket.java:372)
    at java.net.Socket.(Socket.java:186)
    at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22)
    at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128)
    at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595)
    … 8 more

    2009/10/23 09:29:11 INFO – jmeter.engine.StandardJMeterEngine: Test has ended

  16. Bonjour,

    Ton erreur provient du fichier /etc/hosts sur le serveur (si je me souviens bien, sinon c’est du coté de l’injecteur).
    Dans la deuxième ligne de ce fichier, il y a
    127.0.1.1 localhost ou le nom du machine

    Il faut le remplacer par
    xxx.xxx.xxx.xxx nom_de_machine
    où xx est l’adresse de ta machine (pas une adresse 127.xxxxx)

    A+
    Milamber

  18. Bonjour,

    En premier lieu, un grand merci pour l’ensemble des billets sur JMeter très complets.

    Je fais un test distribué vers deux injecteurs avec 4 threads chacun.
    Mes résultats en CSV récupérés par le contrôleur sont de cet ordre:
    timeStamp,elapsed,label,threadName,success,bytes,grpThreads,allThreads,Hostname
    …
    09:07:19.863,16,05-Action 5,Scenario 5,true,391,4,4,D30810
    09:07:29.406,16,06-Action 6,Scenario 5,true,392,4,4,D30810
    …
    09:07:25.385,27,05-Action 5,Scenario 5,true,391,4,4,D30609
    09:07:35.338,20,06-Action 6,Scenario 5,true,392,4,4,D30609
    …
    Hors, je souhaiterais avoir allThreads à 8 (nombre total de threads attaquant le serveur au moment de l’appel de l’action)
    Est-ce que JMeter peut faire ça?

  19. Bonjour,

    Le champ allThreads ne peut pas être à 8 dans ton (un) tir distribué (désolé). JMeter ne permettant pas une communication entre chaque injecteur (sous-entendu JVM) pour qu’ils s’indiquent leur nombre courant de threads, afin ensuite de l’additionner.

    A+
    Milamber

  20. C’est bien ce que je craignais.
    Tant pis 🙁
    Merci pour ta réponse en tout cas.

  21. Bonjour,
    Durant mes tirs de charges utilisant JMeter en mode interface graphique et des requêtes Http, j’ai noté les points d’interrogations suivants:

    1. Lors d’un blocage d’un tir de charge comment on tranche si le serveur est coincé oubien notre poste de travail n’a plus les ressources nécessaire (mémoire, bande passante,..)?

    2. Lorsqu’on fournit notre rapport de stress de charge: on remarque qu’il diffère d’une machine à l’autre. peut être lié au débit, et peut être à d’autres performences de la machine. donc j’ai pensé à décrire l’environnement de test de charge pour chaque tir: si vous êtes d’accord, alors quels sont les informations sur ma machine que doit contenir le rapport de stress de charge?

    Pourriez vous m’aider à éclaircir ces points?

    Merci infiniment!!

    Hanene.

  22. Bonjour,

    1. Pendant un tir de charges, il faut supervision les ressources systèmes du ou des serveurs cibles et ceux de la machine JMeter. C’est à dire la CPU, la mémoire, le réseau et l’utilisation du disque, etc… Il existe une multitude d’outils sur chaque OS pour le faire.

    2. Dans le rapport, il faut en effet décrire l’environnement technique de manière sommaire (CPU, Memoire, Bande passante réseau, Distance réseaux (nombre de routeur entre les deux points), etc). Il faut aussi mettre le plan de test de charges (comment la charge sera envoyée vers le serveur (tir par palier, un VU nouveau chaque minute, etc…). Bien entendu, il faut donner les résultats (tableau/graphique/histogramme) et procéder à une analyse de ces résultats. C’est ici qu’intervient l’utilisation des métriques systèmes qui ont été supervisés pendant le tir. Ils viennent aider à comprendre les résultats soit de manière unitaire (un seul tir) ou soit de manière plus globale pour expliquer les différences entre deux mêmes tirs.
    Par exemple, le tir A est fait sur le serveur 1 avec un temps de réponses moyen de 3,5 sec et le tir B est fait sur le serveur 2 avec un temps de réponses moyen de 2,5 sec. On observe sur la courbe de l’utilisation CPU du serveur 1 : 80% tandis que sur le serveur 2 la CPU est à seulement 60%. Conclusion le serveur B semble mieux dimensionné que le serveur A pour tenir la charge, et devrait pourvoir supporté quelques utilisateurs de plus.

    A+
    Milamber

  23. Bonjour,

    Mon test JMeter comprend une source de données CSV en entrée. (requêtes WS a exécuter)
    Lors de l’execution du scenario sur les injecteurs, java.io.FileNotFoundException: .\data\extract_bak.csv (Le chemin d’accès spécifié est introuvable).
    Cela veut donc tir que le fichier n’est pas transféré en même temps que le scénario.

    J’aurai voulu soit :
    1. que le contrôleur transmette aux injecteurs les données à jouer issues du fichier source (afin de ne pas jouer deux fois les requêtes)
    2. soit donner un nom de fichier différent à chaque injecteur (paramétrer le composant fichier source en fonction de l’injecteur)

    Sinon me reste la solution de déployer dans un répertoire sur chaque injecteur le fichier et le référencer dans le contrôleur en chemin absolu (c:/data …)
    Mais je trouve ça moins dynamique.

    Je n’ai pas su voir d solutions pour le point 1 et2 .

Les commentaires sont fermés.