jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <pmoua...@apache.org>
Subject Re: Avoid thread sleep on delays
Date Fri, 18 Oct 2019 19:17:21 GMT
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 <sitnikov.vladimir@gmail.com>
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
>

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