jmeter-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 61556] New: Performance regression with IfController and JS, Groovy evaluations
Date Thu, 21 Sep 2017 11:15:56 GMT

            Bug ID: 61556
           Summary: Performance regression with IfController and JS,
                    Groovy evaluations
           Product: JMeter
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: regression
          Priority: P2
         Component: Main
  Target Milestone: ---

Created attachment 35346
Groovy condition evaluation

There appears to be a regression in performance with the move from 3.1 to 3.2
in the evaluation of IfController in JS.  This appears to be a slow memory leak
and only was noticeable in running tests with 500 tps over a period of 4 hours.

Jexl evaluation appears to be the same as before.  Groovy evaluation can also
lead to a OOM in metaspace, although this is not limited by default in Jmeter!
Which it should be.

I attached some examples tests, which execute a debug controller with a delay,
then evaluates a condition before executing another debug controller with the
same delay.  Metaspace limited to 256mb.  The condition is of the form:

Summary of results (test files attached)

Jmeter 3.2

Groovy evaluation = failed after 3 mins with out of memory in metaspace.
JS evaluation = 1808 transactions/s
Jexl evaluation = 1980 transactions/s

Jmeter 3.1

Groovy evaluation = 223 transactions/s
JS evaluation = 1963 transactions/s
Jexl evaluation = 1982 transactions/s

I have attached the results as well as screen shots of the metaspace and cpu
through jvisualvm.

So here are two issues really:

1.  Performance degradation (possible slow metaspace leak) on JS evaluation in
2.  Documentation needs to be clearer on not using variable replacement in
Groovy scripts either in JSR233 components or in Groovy functions such as in
the IfController.

${__groovy( "${SOME_VAR}" != "DEFAULT" )}

is going to be much slower than

${__groovy(vars.get("SOME_VAR") != "NULL" )}

I assume the later is cached and re-used while the former involve more classes
being created each time and eventually leads to a leak.  What I don't
understand is why the space is not freed up in the metaspace, I would expect it
to be slower but not to cause a OOM and that is the behaviour that differs from
3.1 to 3.2 but I've not run the tests for longer than 5 mins.

We first noticed the issue on longer tests (4 hr) were the throughput was
trending downward towards the end of the test and noticed that the metaspace
was growing throughout the test execution.  This test makes use of quite a few
IfController evaluations in the form:


These are with Interpret Condition as Variable expression = false.

On reverting back to Jmeter 3.1 we did not see the degradation in throughput as
the test continued.

You are receiving this mail because:
You are the assignee for the bug.
View raw message