3

I want to know when checking Cache compiled script if available checkbox is wrong,

Following Best practices there are some situations that Cache compiled script shouldn't be used, but the example of not using ${varName} is wrong, I did a test and the value it's taking is the updated value of ${varName} and not the first value.

When using JSR 223 elements, it is advised to check Cache compiled script if available property to ensure the script compilation is cached if underlying language supports it. In this case, ensure the script does not use any variable using ${varName} as caching would take only first value of ${varName}.

Does someone knows of a real case it's wrong to use caching?

EDIT

I check using ${varName} in script and there are similar results with/without caching:

I define variable in Jmeter called aa with value 1, and created a script:

def aa = "2";
aa = "3";
log.info("${aa}");

Value 1 was return in both cases of checkbox, so it doesn't relate to caching

Also tried with Beanshell (not compiled language without def aa = "2";) and got same results.

Ori Marko
  • 56,308
  • 23
  • 131
  • 233

2 Answers2

3

What is meant by documentation is that whenever ${varName} has a different value a new entry is stored in cache which will end up filling it with useless data.

So in this case it is wrong and ${varName} should be replaced with

vars.get("varName")

In fact I don't see real reason for unchecking this option provided you use the right JMeter syntax

The option is unchecked by default due to the risk described above and also for "non consensus" reasons:

As to performance, it is exactly the same wether or not you check it for a language that does not support compilation as the first thing JMeter does is to check "supportsCompilable" before using the checkbox, see:

UBIK LOAD PACK
  • 33,980
  • 5
  • 71
  • 116
0

You should not be using caching when you use a scripting engine which does not support caching if compiled scripts. Since only Groovy is capable of compiling scripts you should tick this box for Groovy and untick for the other engines (the code block which does not make sense will be triggered each time the script will be called)

Well-behaved Groovy engine should:

  1. Compile script in the runtime to avoid interpretation each time
  2. Cache compiled script to avoid recompilation
  3. Recompile script and update the cache if any changes are being made to it.

Inlining JMeter functions and variables into scripts is a little bit dangerous for any language as it might resolve into something which cause compilation failure or even even worse result in code which you don't expect. In case of Groovy JMeter Variables syntax conflicts with Groovy GString template

So inlining variables will cause overhead for recompiling the script each time it's called.

So please continue following JMeter's Best Practices and remember one more little tip: avoid scripting where possible as none scripting option performance behaves as fast as Java does, check out Beanshell vs JSR223 vs Java JMeter Scripting: The Performance-Off You've Been Waiting For! guide for details.

Dmitri T
  • 159,985
  • 5
  • 83
  • 133
  • When I checked other languages support caching, see https://stackoverflow.com/questions/45708631/jmeter-script-engine-which-allow-caching-and-compilation for exampe jexl https://commons.apache.org/proper/commons-jexl/apidocs/org/apache/commons/jexl3/scripting/JexlScriptEngine.html – Ori Marko Sep 26 '17 at 06:20