jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Advice: How to test a stateful client/server application (is the "client" the thread or threadgroup)
Date Wed, 30 Mar 2011 11:42:29 GMT
On 30 March 2011 12:10, Sonam Chauhan <> 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
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 <> 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:
>> "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,
>> 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
>> 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
>> (
>> ).
>> 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:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message