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]
