You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Malith Jayasinghe <ma...@gmail.com> on 2017/07/06 05:00:28 UTC
Maximum number of concurrent users
Hi there,
We are using JMETER 3.2 to do a series of performance tests (stress
testing) with a large number of concurrent users (3000, 4000).
These performance tests are very basic tests where there is only single
HTTP request (per user).
We have noticed that load average is extremely high (= 1000, on a 4 core)
under high concurrencies (2000, 3000, 4000) and we are also noticed that
there are large spikes (max) in the performance results.
What is a maximum number of concurrent users single JMETER instance can
handle in a scenario like this?
Re: Maximum number of concurrent users
Posted by Malith Jayasinghe <ma...@gmail.com>.
Thank you.
On Thu, Jul 6, 2017 at 4:18 PM, Felix Schumacher <
felix.schumacher@internetallee.de> wrote:
>
>
> Am 6. Juli 2017 10:06:11 MESZ schrieb Malith Jayasinghe <
> malith.jayasinghe@gmail.com>:
> >Thanks a lot for your reply again.
> >
> >Could you please clarify the following.
> >
> >1) If I create a thread group in JMETER and specify 1000 users, JMETER
> >creates 1000 threads when I run the test?
>
> What you do in a thread is up to you, but generally it is assumed, that
> one thread equals to one user.
> This is especially true, if you look at things like the http cache or
> cookie manager.
>
> >
> >2) If the above is true, can we actually rely on the performance
> >results
> >obtained under such high number of users (because CPU will be shared
> >among
> >these threads and there will be a lot of context switches etc + very
> >high
> >load average )?
>
> It's strongly advised, that you keep an eye on every component of your
> test setup. That includes the JMeter server(s).
>
> A JMeter server that is overloaded (CPU, memory, disk or network) will
> give unreliable results.
>
> >
> >3) Is there a way in JMETER to control the ratio between the numbers of
> >threads and connections (similar to WRK)? This way we can create fewer
> >numbers of threads and a higher number of connections?
>
> Not at the moment.
>
> Felix
>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >On Thu, Jul 6, 2017 at 11:05 AM, Felix Schumacher <
> >felix.schumacher@internetallee.de> wrote:
> >
> >>
> >>
> >> Am 6. Juli 2017 07:00:28 MESZ schrieb Malith Jayasinghe <
> >> malith.jayasinghe@gmail.com>:
> >> >Hi there,
> >> >
> >> >We are using JMETER 3.2 to do a series of performance tests (stress
> >> >testing) with a large number of concurrent users (3000, 4000).
> >> >
> >> >These performance tests are very basic tests where there is only
> >single
> >> >HTTP request (per user).
> >> >
> >> >We have noticed that load average is extremely high (= 1000, on a 4
> >> >core)
> >> >under high concurrencies (2000, 3000, 4000) and we are also noticed
> >> >that
> >> >there are large spikes (max) in the performance results.
> >> >
> >> >What is a maximum number of concurrent users single JMETER instance
> >can
> >> >handle in a scenario like this?
> >>
> >> There is no easy answer to this question.
> >>
> >> In https://bz.apache.org/bugzilla/show_bug.cgi?id=61254 there seem to
> >be
> >> 300.000 concurrent threads involved (on 60 JMeter clients).
> >>
> >> On a moderate single machine with a simple test plan (and enough ram)
> >I
> >> would expect 1000 to 2000 threads to work with no real problem.
> >>
> >> Blazemeter just published a blog post about The Max Number of
> >threads:
> >> https://www.blazemeter.com/blog/what’s-the-max-number-of-
> >> users-you-can-test-on-jmeter
> >>
> >> I would definitely look at your JVM memory stats. It is probably
> >doing a
> >> lot of work in the garbage collector.
> >>
> >> If you are using JavaScript as scripting language, you should change
> >those
> >> to jexl3 or groovy. Nashorn behaves badly in highly concurrent
> >scenarios.
> >>
> >> Regards,
> >> Felix
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> >> For additional commands, e-mail: user-help@jmeter.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>
Re: Maximum number of concurrent users
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 6. Juli 2017 10:06:11 MESZ schrieb Malith Jayasinghe <ma...@gmail.com>:
>Thanks a lot for your reply again.
>
>Could you please clarify the following.
>
>1) If I create a thread group in JMETER and specify 1000 users, JMETER
>creates 1000 threads when I run the test?
What you do in a thread is up to you, but generally it is assumed, that one thread equals to one user.
This is especially true, if you look at things like the http cache or cookie manager.
>
>2) If the above is true, can we actually rely on the performance
>results
>obtained under such high number of users (because CPU will be shared
>among
>these threads and there will be a lot of context switches etc + very
>high
>load average )?
It's strongly advised, that you keep an eye on every component of your test setup. That includes the JMeter server(s).
A JMeter server that is overloaded (CPU, memory, disk or network) will give unreliable results.
>
>3) Is there a way in JMETER to control the ratio between the numbers of
>threads and connections (similar to WRK)? This way we can create fewer
>numbers of threads and a higher number of connections?
Not at the moment.
Felix
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>On Thu, Jul 6, 2017 at 11:05 AM, Felix Schumacher <
>felix.schumacher@internetallee.de> wrote:
>
>>
>>
>> Am 6. Juli 2017 07:00:28 MESZ schrieb Malith Jayasinghe <
>> malith.jayasinghe@gmail.com>:
>> >Hi there,
>> >
>> >We are using JMETER 3.2 to do a series of performance tests (stress
>> >testing) with a large number of concurrent users (3000, 4000).
>> >
>> >These performance tests are very basic tests where there is only
>single
>> >HTTP request (per user).
>> >
>> >We have noticed that load average is extremely high (= 1000, on a 4
>> >core)
>> >under high concurrencies (2000, 3000, 4000) and we are also noticed
>> >that
>> >there are large spikes (max) in the performance results.
>> >
>> >What is a maximum number of concurrent users single JMETER instance
>can
>> >handle in a scenario like this?
>>
>> There is no easy answer to this question.
>>
>> In https://bz.apache.org/bugzilla/show_bug.cgi?id=61254 there seem to
>be
>> 300.000 concurrent threads involved (on 60 JMeter clients).
>>
>> On a moderate single machine with a simple test plan (and enough ram)
>I
>> would expect 1000 to 2000 threads to work with no real problem.
>>
>> Blazemeter just published a blog post about The Max Number of
>threads:
>> https://www.blazemeter.com/blog/what’s-the-max-number-of-
>> users-you-can-test-on-jmeter
>>
>> I would definitely look at your JVM memory stats. It is probably
>doing a
>> lot of work in the garbage collector.
>>
>> If you are using JavaScript as scripting language, you should change
>those
>> to jexl3 or groovy. Nashorn behaves badly in highly concurrent
>scenarios.
>>
>> Regards,
>> Felix
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> For additional commands, e-mail: user-help@jmeter.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: Maximum number of concurrent users
Posted by Malith Jayasinghe <ma...@gmail.com>.
Thanks a lot for your reply again.
Could you please clarify the following.
1) If I create a thread group in JMETER and specify 1000 users, JMETER
creates 1000 threads when I run the test?
2) If the above is true, can we actually rely on the performance results
obtained under such high number of users (because CPU will be shared among
these threads and there will be a lot of context switches etc + very high
load average )?
3) Is there a way in JMETER to control the ratio between the numbers of
threads and connections (similar to WRK)? This way we can create fewer
numbers of threads and a higher number of connections?
On Thu, Jul 6, 2017 at 11:05 AM, Felix Schumacher <
felix.schumacher@internetallee.de> wrote:
>
>
> Am 6. Juli 2017 07:00:28 MESZ schrieb Malith Jayasinghe <
> malith.jayasinghe@gmail.com>:
> >Hi there,
> >
> >We are using JMETER 3.2 to do a series of performance tests (stress
> >testing) with a large number of concurrent users (3000, 4000).
> >
> >These performance tests are very basic tests where there is only single
> >HTTP request (per user).
> >
> >We have noticed that load average is extremely high (= 1000, on a 4
> >core)
> >under high concurrencies (2000, 3000, 4000) and we are also noticed
> >that
> >there are large spikes (max) in the performance results.
> >
> >What is a maximum number of concurrent users single JMETER instance can
> >handle in a scenario like this?
>
> There is no easy answer to this question.
>
> In https://bz.apache.org/bugzilla/show_bug.cgi?id=61254 there seem to be
> 300.000 concurrent threads involved (on 60 JMeter clients).
>
> On a moderate single machine with a simple test plan (and enough ram) I
> would expect 1000 to 2000 threads to work with no real problem.
>
> Blazemeter just published a blog post about The Max Number of threads:
> https://www.blazemeter.com/blog/what’s-the-max-number-of-
> users-you-can-test-on-jmeter
>
> I would definitely look at your JVM memory stats. It is probably doing a
> lot of work in the garbage collector.
>
> If you are using JavaScript as scripting language, you should change those
> to jexl3 or groovy. Nashorn behaves badly in highly concurrent scenarios.
>
> Regards,
> Felix
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>
Re: Maximum number of concurrent users
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 6. Juli 2017 07:00:28 MESZ schrieb Malith Jayasinghe <ma...@gmail.com>:
>Hi there,
>
>We are using JMETER 3.2 to do a series of performance tests (stress
>testing) with a large number of concurrent users (3000, 4000).
>
>These performance tests are very basic tests where there is only single
>HTTP request (per user).
>
>We have noticed that load average is extremely high (= 1000, on a 4
>core)
>under high concurrencies (2000, 3000, 4000) and we are also noticed
>that
>there are large spikes (max) in the performance results.
>
>What is a maximum number of concurrent users single JMETER instance can
>handle in a scenario like this?
There is no easy answer to this question.
In https://bz.apache.org/bugzilla/show_bug.cgi?id=61254 there seem to be 300.000 concurrent threads involved (on 60 JMeter clients).
On a moderate single machine with a simple test plan (and enough ram) I would expect 1000 to 2000 threads to work with no real problem.
Blazemeter just published a blog post about The Max Number of threads: https://www.blazemeter.com/blog/what’s-the-max-number-of-users-you-can-test-on-jmeter
I would definitely look at your JVM memory stats. It is probably doing a lot of work in the garbage collector.
If you are using JavaScript as scripting language, you should change those to jexl3 or groovy. Nashorn behaves badly in highly concurrent scenarios.
Regards,
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org