jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <>
Subject Re: Avoid thread sleep on delays
Date Fri, 18 Oct 2019 18:48:30 GMT
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.


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