When running load tests in Apache JMeter, in many cases it’s necessary to choose a post processor/scripting language for certain tasks, such as handling SampleResult variables, assigning dynamic names to samplers, or just adding some logic to scripts. We have several options to choose from, but in this post, we will look at two in particular: BeanShell vs Groovy and why we are partial to Groovy. But, instead of trying to convince you why we believe Groovy is the better choice, we’ll present the facts and let them speak for themselves!

BeanShell is a small, free, embeddable Java source interpreter with object scripting language features, written in Java. BeanShell dynamically executes standard Java syntax and extends it with common scripting conveniences such as loose types, commands, and method closures like those in Perl and JavaScript.

Apache Groovy, on the other hand, is a dynamic object-oriented programming language that can be used as a scripting language for the Java platform.

Let’s take a deeper look at the main characteristics of each:

BeanShell

1. Supports for loops and foreach loops.
2. Syntax for array initialization is similar to Java.
3. BeanShell can’t run a script written for Groovy as it is based on JDK1.4, so it has no generic features.
4. Execution environment is 1.4 or more, but doesn’t support generics.
5. Doesn’t support writing a method with variable arguments or calling a method with variable arguments.
6. Doesn’t support assigning certain hexadecimal values to the primitive data types. For example, int i = 0x80018000 throws an exception from the BeanShell interpreter saying the size is big. A BigInteger is to be used in this case, which is, again, tedious as we have to do something like this: BigInteger i = new BigInteger(“0x80018000”);

Apache Groovy

1. Groovy engine can run a script written for BeanShell.
2. Supports generics and collections with generics. Also supports raw types e.g.> ArrayList str = new ArrayList().
3. Supports calling methods with variable arguments, e.g. method(int…i).
4. Supports primitive data types like int to assign 4 byte hexa-decimal values eg. int i = 0x80018000.
5. The syntax for array initialization is a bit different from Java, e.g. in Java, array is initialized as int[] array = {1,2,3}; in Groovy, it’s done as int[] array = [1,2,3].
6. Supports for loops and foreach loops, etc.
7. Development and support: the Groovy language is constantly being developed, maintained, and supported.
8. Java compatibility: valid Java code in 99% of cases will be valid Groovy code.
9. Groovy scripts can be statically compiled providing near Java code performance.
10. Native support for regular expressions, XML, JSON.
11. Simplified work with files.

Perhaps one of the most important features that we have mentioned about Groovy is the fact that it’s statically compiled, which means that we can obtain top-notch performance, similar to what we would achieve using Java.

To see the difference in performance, we can take a look at the following chart from this helpful blog post, comparing BeanShell against other PostProcessors using Groovy and JavaScript:

We can clearly observe that Groovy results in outstanding performance where it reduces the time by half when executing on BSF Sampler (Bean Scripting Framework) and nearly a quarter when executing on a JSR223 Sampler (what replaces BSF nowadays).

More great aspects of Groovy are, for example, its syntax, which is pretty straightforward, enabling you to write everyday sentences rapidly. Another feature that is also very useful is the __groovy() function that was introduced in the 3.1 version of JMeter. This function allows us to evaluate Groovy code anywhere in the script where usual functions can be placed.

Let’s take a look at an easy example just to make things clear, we have a certain variable:

And then we would like to use that value in a simple HTTP request as follows:

As you can see __groovy() function can be evaluated almost anywhere in the script, in this example we declared a variable with the text “It’s Groovy Right?” and then we applied a substring Groovy function to it and the result is being shown on the name of the sampler.

Finally, another functionality that I found really interesting is that Groovy gives us the possibility of executing OS commands within the code using “My_command”.execute() or if we want to maintain the output in jmeter.log, we can use “My_command”.execute().text like in the example below:

It may take some time to adapt to Groovy. Even so, I think that after reading this brief summary of its pros and cons, you will seriously want to consider migrating your post processors right into Groovy, so you can take real advantage of the outstanding performance and new features that it has to offer.

We want to know: what are your experiences with Groovy?