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