Commentaires sur : Exécuter son scénario de tir de charge

Par : Milamber

Milamber — Wed, 05 Oct 2011 18:37:41 +0000

Voilà le moyen de le faire en ligne de commande :
http://jakarta.apache.org/jmeter/usermanual/get-started.html#proxy_server

Par : yann

yann — Wed, 05 Oct 2011 14:10:52 +0000

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.

Par : yann

yann — Wed, 05 Oct 2011 13:43:59 +0000

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.

Par : yann

yann — Wed, 05 Oct 2011 13:23:19 +0000

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.

Par : AlKP77

AlKP77 — Sun, 28 Aug 2011 13:56:09 +0000

Bravo… Vraiment bravo

Par : Soleil

Soleil — Fri, 21 Aug 2009 14:09:34 +0000

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

Par : Milamber

Milamber — Thu, 20 Aug 2009 08:39:52 +0000

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

Par : Soleil

Soleil — Thu, 20 Aug 2009 07:56:39 +0000

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

Par : Milamber

Milamber — Wed, 19 Aug 2009 16:59:15 +0000

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

Par : Soleil

Soleil — Wed, 19 Aug 2009 10:00:44 +0000

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