jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <>
Subject Re: JSR223 elements performance
Date Sat, 29 Aug 2015 19:53:10 GMT
>> 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.

Of course it can. What if we leave a kind of
property to revert old behavior?
In fact, "global scope sharing/unsharing" is undefined behavior (I do
not find it documented), thus we can just tweak it to suit the
majority :)

>> 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?

Unfortunately, it does not. Even with a "cache key", the simple loop
above is slow: it takes 1.2 seconds in nashorn javascript while
implementing global scope caching reduces that to 30ms.

>> Does it really make sense to ask user to specify cache key?
> Yes, because only the user knows if the scripts can be shared.

I do not follow you. A script is not data. Sharing scripts should have
no visible impact except "memory consumption" for the cache.

"cache key" just enables compilation cache. The compilation itself
does not touch global scope or variables or whatever.
It just parses the script and creates "ready-to-eval" CompiledScript object.

I believe, the best practice of writing JSR223 scripts (if writing at
all:) is to avoid ${...} interpolations in the script text (it is
In other words, script text should be constant, so I do not see why
JMeter should refrain from caching scripts by default.

>> 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.

Frankly speaking, "cache key" looks like an implementation glitch.
0) "cache key" is somewhat strange. It is rather understandable by a
programmer, but I think it is completely obscure for non-programmers.
It is not clear what are the consequences of non-null cache key.
0) Why cache key is a string? I think it should be just a boolean.
1) Global scope of 223 engine (e.g. javascript globals) is not related
to "cache key". It (global scope sharing) might require yet another
option that tells something like "reuse global scope 223". I do not
think there are cases when users would want having several different
CACHED global contexts.
2) "global scope issue" is not obvious from UI/documentation. The bad
thing is "default" and the only mode is to "spawn new global scope
every time", thus it impacts performance for no apparent reason.


View raw message