jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: JSR223 elements performance
Date Sat, 29 Aug 2015 17:48:56 GMT
On 19 July 2015 at 19:54, Vladimir Sitnikov <> wrote:
> Hello,

Sorry for the long delay in replying

> I'm looking into JSR223 samplers performance and here are my findings.
> The question is "what is the expected behavior of JSR223
> samplers/assertions/etc in regard to global variables?"
> In other words, what if sampler A defines new global and a subsequent
> sampler B tries to access it.
> 1) It might take a while to instantiate a ScriptEngine.
> That's simple: just a thread local (or a Map<String, ScriptEngine>
> field in the JMeterThread).

Perhaps, but ThreadLocal has disadvantages - entries need to be
disposed of at the end of the thread.

> 2) It might take a while to initialize script context (see below).
> 3) It is strange that compilation keys have to be manually specified.
> Does it really make sense to ask user to specify cache key?

Yes, because only the user knows if the scripts can be shared.

> What if JMeter created cache key automatically?
> Here's more on #2
> For instance, consider JavaScript: when it initializes, it needs to
> populate "global scope" with all the defaults (RegExp, Number, String,
> etc, etc).
> It might happen script itself defines some global variables or
> redefines out of the box ones.

That is why the cache key is manually provided.

> Here's the script I use to measure the performance (JDK 1.8u40,
> engine==javascript):
> var tmp
> for(var i=0; i<300; i++) {
>   tmp = vars.get("TESTSTART.MS"); vars.put("TESTSTART.MS", tmp);
> }
> It takes ~1.2 seconds when executing this loop 1000 times (300'000
> puts & gets) with all defaults (~ 4000ns per get+put)
> If I cache ScriptEngine the response time reduces to 600ms (~ 2000ns
> per get+put)
> If I additionally reuse ScriptContext the response time reduces to
> 30ms  (~ 100ns per get+put)
> So, the question boils down to:
> 2.1) What if we just "reuse global scope" between all the samplers in
> the current thread? At the end, users should write proper code
> (without global variables)

That might break existing test plans.

> 2.2) If "reuse global scope always" is considered a no-go solution,
> should we add a UI checkbox to "enable/disable" sharing?

Surely that's what the cache key already achieves?

> --
> Regards,
> Vladimir Sitnikov

View raw message