jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malith Jayasinghe <malith.jayasin...@gmail.com>
Subject Re: Maximum number of concurrent users
Date Thu, 06 Jul 2017 11:18:08 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message