You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Barrie Treloar <ba...@gmail.com> on 2011/03/30 08:28:45 UTC
Advice: How to test a stateful client/server application (is the
"client" the thread or threadgroup)
I'm looking for advice on how to design JMeter tests so I can test a
stateful client/server application.
The confusion is around whether the "client" (or user) is the Thread
or ThreadGroup.
This is made a little bit more complicated in that we are simulating a
Java client communicating to a server.
The client can invoke multiple requests on the server concurrently and
I am struggling to work out how to write test plans or JavaSampler
plugins to mimic this.
The closest I can see is this:
http://wiki.apache.org/jakarta-jmeter/JMeterFAQ#How_do_I_ensure_each_http_request_for_jsp_is_within_one_jsessionid_.3F
"Just insert a http cookie manager. It will automatically handle the
session for all the request within the threadgroup treating it like
one session. Without http cookie manager, each request is a new
session as no session state is kept. jsessionid is only shown for the
very first request, subsequent request will not see the jsessionid. to
use a variable in jmeter is ${name of variable}."
However this needs to be tempered with these two sections:
1) From http://jakarta.apache.org/jmeter/usermanual/test_plan.html,
Section 4.1 ThreadGroup
"Each thread will execute the test plan in its entirety and completely
independently of other test threads. Multiple threads are used to
simulate concurrent connections to your server application."
2) From http://jakarta.apache.org/jmeter/usermanual/build-web-test-plan.html,
Section 5.1 Adding Users
"The first step you want to do with every JMeter Test Plan is to add a
Thread Group element. The Thread Group tells JMeter the number of
users you want to simulate, how often the users should send requests,
and the how many requests they should send."
So in 2) a Thread == User, but to have state across the JMeter client
application then you need ThreadGroup == User as per 1).
And that state needs to be stored somewhere, for HTTP you can use the
HttpCookieManager. I'll have to write something similar for Java
Samplers.
Also the Logic Controllers are what drive which Sampler to run next
(http://jakarta.apache.org/jmeter/usermanual/component_reference.html#logic_controllers).
What's not apparent is whether I can have two samplers running at the
same time within the logic controller.
Everything in the documentation seems to indicate that only one
Sampler is running at a time within the Thread.
If it was possible to have multiple Samplers running then they better
not block the thread that is running them.
Running multiple samplers at the same time would solve my problem, if
there was a way not to block the thread running them.
This all seems to indicate that if I have Thread == User, and because
only one Sampler will be running at a time, that there can only every
be one concurrent request to the server for that User.
To simulate the client sending concurrent requests to the server I
have to use ThreadGroup == User.
This complicates the test plan as you have to remember that each
Thread != User and using ThreadGroup == User means there is no easy
way to create multiple users.
To create multiple users with Thread == User, you change the Thread
Group > Thread Property "Number of threads (users)" and the "Ramp-Up
period" and you have more users.
To create multiple users with ThreadGroup == User, you need to copy
the ThreadGroup and paste a new instance for each user you require,
changing the Number of threads doesn't create more users, it only
increases the concurrency of the current user.
The switch from ThreadGroup == User instead of Thread == User is still
causing me some confusion in trying to work out responsibilities.
Especially since all the GUI screens are written with the assumption
that Thread == User.
Does anyone have any advice?
(apologies for the complicated email, I hope it is understandable)
Barrie
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Advice: How to test a stateful client/server application (is the
"client" the thread or threadgroup)
Posted by Barrie Treloar <ba...@gmail.com>.
On Wed, Mar 30, 2011 at 10:12 PM, sebb <se...@gmail.com> wrote:
>> The problem in that your case is your client makes concurrent requests. What
>> you need is nested thread groups.
>
> However JMeter does not support nested thread groups.
>
[del]
> Generally what is important is ensuring that the load on the server is
> representative, and one way to do this is to increase the number of
> threads.
> Another way is to reduce the time delays.
>
> Adjust until the required request rate is achieved.
I also need to test the load per-client, since the client can run
concurrent requests, I want to make sure that the server can cope with
this load and see what happens.
It's good to know I wasting going insane with how User was meant to behave.
But it sounds like there is no alternative than to go with my "hack"
of using ThreadGroup == User and make sure it gets adequately
explained to our test users.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Advice: How to test a stateful client/server application (is the
"client" the thread or threadgroup)
Posted by sebb <se...@gmail.com>.
On 30 March 2011 12:10, Sonam Chauhan <so...@gmail.com> wrote:
> To my knowledge, JMeter's usage is predicated on the "Thread = User"
> assumption.
Yes, that is correct.
> The "ThreadGroup = User" seems to be a misinterpretation of the
> documentation ( # 1 quoted below).
Yes, that is very misleading. I'll try and make that clearer.
> JMeter basic paradigm seems to be that a JMeter thread models one user
> making one request at a time to the server. With AJAX, web-workers etc. of
> course this isn't true, but its close enough. (Exception: I think the HTTP
> sampler has a download embedded resources -- not sure if this happens in
> parallel or not.)
Not in 2.4.
Parallel download has been implemented, and will be in the next release.
> The problem in that your case is your client makes concurrent requests. What
> you need is nested thread groups.
However JMeter does not support nested thread groups.
> Or you can 'split' one user across multiple thread groups. Lets say you have
> 200 users who each make 10 concurrent requests every 3 seconds. You could
> have 10 thread groups, each with 200 users, executing requests with
> appropriate delays.
Generally what is important is ensuring that the load on the server is
representative, and one way to do this is to increase the number of
threads.
Another way is to reduce the time delays.
Adjust until the required request rate is achieved.
> Regards
> Sonam
>
> On Wed, Mar 30, 2011 at 5:28 PM, Barrie Treloar <ba...@gmail.com> wrote:
>
>> I'm looking for advice on how to design JMeter tests so I can test a
>> stateful client/server application.
>> The confusion is around whether the "client" (or user) is the Thread
>> or ThreadGroup.
>>
>> This is made a little bit more complicated in that we are simulating a
>> Java client communicating to a server.
>> The client can invoke multiple requests on the server concurrently and
>> I am struggling to work out how to write test plans or JavaSampler
>> plugins to mimic this.
>>
>> The closest I can see is this:
>>
>>
>> http://wiki.apache.org/jakarta-jmeter/JMeterFAQ#How_do_I_ensure_each_http_request_for_jsp_is_within_one_jsessionid_.3F
>>
>> "Just insert a http cookie manager. It will automatically handle the
>> session for all the request within the threadgroup treating it like
>> one session. Without http cookie manager, each request is a new
>> session as no session state is kept. jsessionid is only shown for the
>> very first request, subsequent request will not see the jsessionid. to
>> use a variable in jmeter is ${name of variable}."
>>
>> However this needs to be tempered with these two sections:
>>
>> 1) From http://jakarta.apache.org/jmeter/usermanual/test_plan.html,
>> Section 4.1 ThreadGroup
>> "Each thread will execute the test plan in its entirety and completely
>> independently of other test threads. Multiple threads are used to
>> simulate concurrent connections to your server application."
>>
>> 2) From
>> http://jakarta.apache.org/jmeter/usermanual/build-web-test-plan.html,
>> Section 5.1 Adding Users
>> "The first step you want to do with every JMeter Test Plan is to add a
>> Thread Group element. The Thread Group tells JMeter the number of
>> users you want to simulate, how often the users should send requests,
>> and the how many requests they should send."
>>
>> So in 2) a Thread == User, but to have state across the JMeter client
>> application then you need ThreadGroup == User as per 1).
>> And that state needs to be stored somewhere, for HTTP you can use the
>> HttpCookieManager. I'll have to write something similar for Java
>> Samplers.
>>
>> Also the Logic Controllers are what drive which Sampler to run next
>> (
>> http://jakarta.apache.org/jmeter/usermanual/component_reference.html#logic_controllers
>> ).
>> What's not apparent is whether I can have two samplers running at the
>> same time within the logic controller.
>> Everything in the documentation seems to indicate that only one
>> Sampler is running at a time within the Thread.
>> If it was possible to have multiple Samplers running then they better
>> not block the thread that is running them.
>> Running multiple samplers at the same time would solve my problem, if
>> there was a way not to block the thread running them.
>>
>> This all seems to indicate that if I have Thread == User, and because
>> only one Sampler will be running at a time, that there can only every
>> be one concurrent request to the server for that User.
>>
>> To simulate the client sending concurrent requests to the server I
>> have to use ThreadGroup == User.
>> This complicates the test plan as you have to remember that each
>> Thread != User and using ThreadGroup == User means there is no easy
>> way to create multiple users.
>> To create multiple users with Thread == User, you change the Thread
>> Group > Thread Property "Number of threads (users)" and the "Ramp-Up
>> period" and you have more users.
>> To create multiple users with ThreadGroup == User, you need to copy
>> the ThreadGroup and paste a new instance for each user you require,
>> changing the Number of threads doesn't create more users, it only
>> increases the concurrency of the current user.
>>
>> The switch from ThreadGroup == User instead of Thread == User is still
>> causing me some confusion in trying to work out responsibilities.
>> Especially since all the GUI screens are written with the assumption
>> that Thread == User.
>>
>> Does anyone have any advice?
>> (apologies for the complicated email, I hope it is understandable)
>>
>> Barrie
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Advice: How to test a stateful client/server application (is the
"client" the thread or threadgroup)
Posted by Sonam Chauhan <so...@gmail.com>.
To my knowledge, JMeter's usage is predicated on the "Thread = User"
assumption. The "ThreadGroup = User" seems to be a misinterpretation of the
documentation ( # 1 quoted below).
JMeter basic paradigm seems to be that a JMeter thread models one user
making one request at a time to the server. With AJAX, web-workers etc. of
course this isn't true, but its close enough. (Exception: I think the HTTP
sampler has a download embedded resources -- not sure if this happens in
parallel or not.)
The problem in that your case is your client makes concurrent requests. What
you need is nested thread groups.
Or you can 'split' one user across multiple thread groups. Lets say you have
200 users who each make 10 concurrent requests every 3 seconds. You could
have 10 thread groups, each with 200 users, executing requests with
appropriate delays.
Regards
Sonam
On Wed, Mar 30, 2011 at 5:28 PM, Barrie Treloar <ba...@gmail.com> wrote:
> I'm looking for advice on how to design JMeter tests so I can test a
> stateful client/server application.
> The confusion is around whether the "client" (or user) is the Thread
> or ThreadGroup.
>
> This is made a little bit more complicated in that we are simulating a
> Java client communicating to a server.
> The client can invoke multiple requests on the server concurrently and
> I am struggling to work out how to write test plans or JavaSampler
> plugins to mimic this.
>
> The closest I can see is this:
>
>
> http://wiki.apache.org/jakarta-jmeter/JMeterFAQ#How_do_I_ensure_each_http_request_for_jsp_is_within_one_jsessionid_.3F
>
> "Just insert a http cookie manager. It will automatically handle the
> session for all the request within the threadgroup treating it like
> one session. Without http cookie manager, each request is a new
> session as no session state is kept. jsessionid is only shown for the
> very first request, subsequent request will not see the jsessionid. to
> use a variable in jmeter is ${name of variable}."
>
> However this needs to be tempered with these two sections:
>
> 1) From http://jakarta.apache.org/jmeter/usermanual/test_plan.html,
> Section 4.1 ThreadGroup
> "Each thread will execute the test plan in its entirety and completely
> independently of other test threads. Multiple threads are used to
> simulate concurrent connections to your server application."
>
> 2) From
> http://jakarta.apache.org/jmeter/usermanual/build-web-test-plan.html,
> Section 5.1 Adding Users
> "The first step you want to do with every JMeter Test Plan is to add a
> Thread Group element. The Thread Group tells JMeter the number of
> users you want to simulate, how often the users should send requests,
> and the how many requests they should send."
>
> So in 2) a Thread == User, but to have state across the JMeter client
> application then you need ThreadGroup == User as per 1).
> And that state needs to be stored somewhere, for HTTP you can use the
> HttpCookieManager. I'll have to write something similar for Java
> Samplers.
>
> Also the Logic Controllers are what drive which Sampler to run next
> (
> http://jakarta.apache.org/jmeter/usermanual/component_reference.html#logic_controllers
> ).
> What's not apparent is whether I can have two samplers running at the
> same time within the logic controller.
> Everything in the documentation seems to indicate that only one
> Sampler is running at a time within the Thread.
> If it was possible to have multiple Samplers running then they better
> not block the thread that is running them.
> Running multiple samplers at the same time would solve my problem, if
> there was a way not to block the thread running them.
>
> This all seems to indicate that if I have Thread == User, and because
> only one Sampler will be running at a time, that there can only every
> be one concurrent request to the server for that User.
>
> To simulate the client sending concurrent requests to the server I
> have to use ThreadGroup == User.
> This complicates the test plan as you have to remember that each
> Thread != User and using ThreadGroup == User means there is no easy
> way to create multiple users.
> To create multiple users with Thread == User, you change the Thread
> Group > Thread Property "Number of threads (users)" and the "Ramp-Up
> period" and you have more users.
> To create multiple users with ThreadGroup == User, you need to copy
> the ThreadGroup and paste a new instance for each user you require,
> changing the Number of threads doesn't create more users, it only
> increases the concurrency of the current user.
>
> The switch from ThreadGroup == User instead of Thread == User is still
> causing me some confusion in trying to work out responsibilities.
> Especially since all the GUI screens are written with the assumption
> that Thread == User.
>
> Does anyone have any advice?
> (apologies for the complicated email, I hope it is understandable)
>
> Barrie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>