number of threads vs number of simulated users

[nicolas de loof <ni...@gmail.com>]

Hi,

There's many threads on this list about simulating high number of users with
jMeter. The main limitation seems to be the number of threads. I wonder why
jMeter uses the "1 dedicated Thread per (Virtual) User" strategy :

   - each Thread uses native memory, large number of threads requires much
   memory
   - Thread context switch consumes CPU time. Switching hundred of threads
   on few cores over-consumes ressources.

So, my question is : is there any plan, or any previous attempt, to use
thread pools in jMeter ? Typically, beeing based on Java 5,
java.util.concurrent provides the adequate thread pooling tools.

Cheers,
Nicolas

Re: number of threads vs number of simulated users

[sebb <se...@gmail.com>]

On 30 July 2010 18:51, Deepak Shetty <sh...@gmail.com> wrote:
> If you have tuned java application servers you know how difficult it is
> getting Thread pool sizing and other archaic java parameters correct - also
> consider the audience expected to use JMeter.
>
> True if you have timers you probably would be able to achieve the same kind
> of throughput with a smaller thread count and pooled threads - However OS
> level thread pooling is far superior to any java capability so it isn't a
> fair comparison. I guess it comes down to I believe scaling by adding
> machines is far simpler to achieve than the complexity added by pooling
> threads.
>

All good points.

Consider how much work JMeter would have to do to preserve the
variables that are local to each thread.
It would have to store them somewhere and recover them for each context switch.

Also, if the timers all happen to expire at the same time, then there
would be no way to execute all the requests unless the pool contained
as many entries as virtual users. In which case the pool is redundant.

If you want to increase the load on the server without increasing the
number of threads, reduce the wait time.

A single JMeter thread can generate much more load than a normal user.

>
> On Thu, Jul 29, 2010 at 11:53 PM, nicolas de loof
> <ni...@gmail.com>wrote:
>
>> This would be true with > N cores available, but the Threads allready have
>> to share the available ones using OS multi-threading "core-pool". There is
>> ALLREADY a backlog queue at OS level for our Threads to execute on limited
>> ressources. Using on Thread per User don't ensure concurrent requests, you
>> will never have more concurrenct that physical core count. Considering
>> "loose" concurency (i.e. active threads during a small time window), a
>> Thread pool would be more efficient that dedicated Threads as less context
>> switches would be necessary.
>>
>> On a realistic scenario we put many Timers, so our thread are moslty doing
>> few stufs and then call Thread.sleep. This generates many Thread context
>> switches with few computation. A Thread-pool would avoid (limit) the ratio
>> between context switches and usefull computation time. There is no way
>> today
>> to create a load with tousand threads, even if the scenario has long sleep
>> time (and then few computation requirements)
>>
>> I agree a Thread-pool requires tunning to set the optimal pool size. This
>> could be a global parameter, and set by default to physicalCoreCount * X.
>>
>> Nicolas
>>
>> 2010/7/29 Deepak Shetty <sh...@gmail.com>
>>
>> > If you want N concurrent requests , you need N threads. Any kind of
>> thread
>> > pool / execute - backlog queue mechanism would only give you an
>> > approximation and in addition would need you to tune the pools based on
>> > your
>> > requirements - which is probably a much harder task.
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Jul 29, 2010 at 4:57 AM, nicolas de loof
>> > <ni...@gmail.com>wrote:
>> >
>> > > Hi,
>> > >
>> > > There's many threads on this list about simulating high number of users
>> > > with
>> > > jMeter. The main limitation seems to be the number of threads. I wonder
>> > why
>> > > jMeter uses the "1 dedicated Thread per (Virtual) User" strategy :
>> > >
>> > >   - each Thread uses native memory, large number of threads requires
>> much
>> > >   memory
>> > >   - Thread context switch consumes CPU time. Switching hundred of
>> threads
>> > >   on few cores over-consumes ressources.
>> > >
>> > > So, my question is : is there any plan, or any previous attempt, to use
>> > > thread pools in jMeter ? Typically, beeing based on Java 5,
>> > > java.util.concurrent provides the adequate thread pooling tools.
>> > >
>> > > Cheers,
>> > > Nicolas
>> > >
>> >
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org

Re: number of threads vs number of simulated users

[Deepak Shetty <sh...@gmail.com>]

If you have tuned java application servers you know how difficult it is
getting Thread pool sizing and other archaic java parameters correct - also
consider the audience expected to use JMeter.

True if you have timers you probably would be able to achieve the same kind
of throughput with a smaller thread count and pooled threads - However OS
level thread pooling is far superior to any java capability so it isn't a
fair comparison. I guess it comes down to I believe scaling by adding
machines is far simpler to achieve than the complexity added by pooling
threads.



On Thu, Jul 29, 2010 at 11:53 PM, nicolas de loof
<ni...@gmail.com>wrote:

> This would be true with > N cores available, but the Threads allready have
> to share the available ones using OS multi-threading "core-pool". There is
> ALLREADY a backlog queue at OS level for our Threads to execute on limited
> ressources. Using on Thread per User don't ensure concurrent requests, you
> will never have more concurrenct that physical core count. Considering
> "loose" concurency (i.e. active threads during a small time window), a
> Thread pool would be more efficient that dedicated Threads as less context
> switches would be necessary.
>
> On a realistic scenario we put many Timers, so our thread are moslty doing
> few stufs and then call Thread.sleep. This generates many Thread context
> switches with few computation. A Thread-pool would avoid (limit) the ratio
> between context switches and usefull computation time. There is no way
> today
> to create a load with tousand threads, even if the scenario has long sleep
> time (and then few computation requirements)
>
> I agree a Thread-pool requires tunning to set the optimal pool size. This
> could be a global parameter, and set by default to physicalCoreCount * X.
>
> Nicolas
>
> 2010/7/29 Deepak Shetty <sh...@gmail.com>
>
> > If you want N concurrent requests , you need N threads. Any kind of
> thread
> > pool / execute - backlog queue mechanism would only give you an
> > approximation and in addition would need you to tune the pools based on
> > your
> > requirements - which is probably a much harder task.
> >
> >
> >
> >
> >
> > On Thu, Jul 29, 2010 at 4:57 AM, nicolas de loof
> > <ni...@gmail.com>wrote:
> >
> > > Hi,
> > >
> > > There's many threads on this list about simulating high number of users
> > > with
> > > jMeter. The main limitation seems to be the number of threads. I wonder
> > why
> > > jMeter uses the "1 dedicated Thread per (Virtual) User" strategy :
> > >
> > >   - each Thread uses native memory, large number of threads requires
> much
> > >   memory
> > >   - Thread context switch consumes CPU time. Switching hundred of
> threads
> > >   on few cores over-consumes ressources.
> > >
> > > So, my question is : is there any plan, or any previous attempt, to use
> > > thread pools in jMeter ? Typically, beeing based on Java 5,
> > > java.util.concurrent provides the adequate thread pooling tools.
> > >
> > > Cheers,
> > > Nicolas
> > >
> >
>

Re: number of threads vs number of simulated users

[nicolas de loof <ni...@gmail.com>]

This would be true with > N cores available, but the Threads allready have
to share the available ones using OS multi-threading "core-pool". There is
ALLREADY a backlog queue at OS level for our Threads to execute on limited
ressources. Using on Thread per User don't ensure concurrent requests, you
will never have more concurrenct that physical core count. Considering
"loose" concurency (i.e. active threads during a small time window), a
Thread pool would be more efficient that dedicated Threads as less context
switches would be necessary.

On a realistic scenario we put many Timers, so our thread are moslty doing
few stufs and then call Thread.sleep. This generates many Thread context
switches with few computation. A Thread-pool would avoid (limit) the ratio
between context switches and usefull computation time. There is no way today
to create a load with tousand threads, even if the scenario has long sleep
time (and then few computation requirements)

I agree a Thread-pool requires tunning to set the optimal pool size. This
could be a global parameter, and set by default to physicalCoreCount * X.

Nicolas

2010/7/29 Deepak Shetty <sh...@gmail.com>

> If you want N concurrent requests , you need N threads. Any kind of thread
> pool / execute - backlog queue mechanism would only give you an
> approximation and in addition would need you to tune the pools based on
> your
> requirements - which is probably a much harder task.
>
>
>
>
>
> On Thu, Jul 29, 2010 at 4:57 AM, nicolas de loof
> <ni...@gmail.com>wrote:
>
> > Hi,
> >
> > There's many threads on this list about simulating high number of users
> > with
> > jMeter. The main limitation seems to be the number of threads. I wonder
> why
> > jMeter uses the "1 dedicated Thread per (Virtual) User" strategy :
> >
> >   - each Thread uses native memory, large number of threads requires much
> >   memory
> >   - Thread context switch consumes CPU time. Switching hundred of threads
> >   on few cores over-consumes ressources.
> >
> > So, my question is : is there any plan, or any previous attempt, to use
> > thread pools in jMeter ? Typically, beeing based on Java 5,
> > java.util.concurrent provides the adequate thread pooling tools.
> >
> > Cheers,
> > Nicolas
> >
>

Re: number of threads vs number of simulated users

[Deepak Shetty <sh...@gmail.com>]

If you want N concurrent requests , you need N threads. Any kind of thread
pool / execute - backlog queue mechanism would only give you an
approximation and in addition would need you to tune the pools based on your
requirements - which is probably a much harder task.





On Thu, Jul 29, 2010 at 4:57 AM, nicolas de loof
<ni...@gmail.com>wrote:

> Hi,
>
> There's many threads on this list about simulating high number of users
> with
> jMeter. The main limitation seems to be the number of threads. I wonder why
> jMeter uses the "1 dedicated Thread per (Virtual) User" strategy :
>
>   - each Thread uses native memory, large number of threads requires much
>   memory
>   - Thread context switch consumes CPU time. Switching hundred of threads
>   on few cores over-consumes ressources.
>
> So, my question is : is there any plan, or any previous attempt, to use
> thread pools in jMeter ? Typically, beeing based on Java 5,
> java.util.concurrent provides the adequate thread pooling tools.
>
> Cheers,
> Nicolas
>