On 19 July 2015 at 19:54, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> 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
