Quite impressive indeed. What about Thread Group plugins (ultimate ...)? I guess they need to be modified to get benefit from that.
Maybe it’s time to have a more user friendly thread group in JMeter core. Regards On Friday, October 18, 2019, Vladimir Sitnikov <[email protected]> wrote: > One more data point: > > Thread Group: threads=100'000, loops=infinite, rampup=0 > Aggregate Report > Debug sampler (properties=false, variables=false, system props=false) > Contant Delay: 1'000ms > > The startup took a while (~5 or so seconds to launch all the "threads", so > after 5 or so seconds JMeter was reading "100'000 active threads") > The aggregate report shows 96'000...98'000 requests per second (this was a > regular GUI mode launched with gradlew runGui). > > ^^^ Isn't that cool? > The context-switch overhead seems to be quite low. > > The whole workload was served by 1-2 native threads. > However, JMeter logs contain the usual "JMeterThread: Thread started: > Thread Group 1-99974" > In other words, the test still thinks it is executed under the old model of > "native OS threads", while in fact, it is multi-tasking. > > So far I'm impressed. > > The sustained memory consumption was 700-800MiB (~ 8KiB per "thread") which > was mainly consumed by the clones of the test plan. > > Even though a single copy of the plan should be enough (do we really need > 100'000 copies of ThreadGroup with 14 "properties" each?), JMeter clones > all the test plan elements for each thread, so we have 100'000 test plans > in memory. > Of course, that is a different story, but it would be nice to reduce the > memory footprint of the running instances. > > Vladimir >
