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 < [email protected]> wrote: > > > Am 6. Juli 2017 07:00:28 MESZ schrieb Malith Jayasinghe < > [email protected]>: > >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: [email protected] > For additional commands, e-mail: [email protected] > >
