Thank you. On Thu, Jul 6, 2017 at 4:18 PM, Felix Schumacher < [email protected]> wrote:
> > > Am 6. Juli 2017 10:06:11 MESZ schrieb Malith Jayasinghe < > [email protected]>: > >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 < > >[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] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
