In previous blog posts we covered how the basic Thread Group is extended to perform more advanced functionality through the Custom Thread Groups package, and other similar plugins such as the Arrivals Thread Group. One that we have yet to discuss is the Open Model Thread Group. Presently, this built-in thread group is still marked as experimental, however it is available and used in current production releases in JMeter.
Conceptually the Open Model Thread Group is similar to many of the Custom Thread Groups in that it allows the test designer to create a load profile defining sustained durations of throughput to a target test application. The primary difference is in the programmatic nature of how these profiles are defined.
Configuring the Open Model Thread Group
For the Open Model Thread Group, the basic configuration takes on the following format:
rate(n/sec) … random_arrivals(x min) … rate(n/sec)
Using the above notation, the rate() functions at the beginning and end specify a change in request rates, while the random_arrivals() function specifies duration over which this change should occur. Valid time units are “sec” or “s” for seconds, “min” or “m” for minutes, and “hour” or “h” for hours. Our configuration can have multiple lines, with each configuration line defining a sequential point in time for our test.
For example, we can specify the following configuration:
rate(0/s) random_arrivals(300 s) rate(10/s) random_arrivals(3600 s) rate(10/s) random_arrivals(300 s) rate(0/s)
This configuration will produce the following load profile:
Advantages of the Open Model Thread Group
When compared to similar profiling thread groups offered in the Custom Thread Groups package for JMeter, the Open Model Thread Group offers the ability for the load profile to be scripted. Highly complex load profiles can be defined in just a few lines of configuration. Here is an example using Groovy scripting:
${__groovy((1..10).collect {
"rate(" + it*10 + "/sec) " +
"random_arrivals(10 sec) " +
"pause(1 sec)"
}.join(" "))}
Large changes in scalability achieved by small modifications. In addition, these load profiles can be made dynamic with the use of Groovy scripting as shown in the example above. The Open Model Thread Group is intelligent enough to be able to interpret many scripts and provide a profile view even when variables are used:
Did you know that RedLine13 offers a full-featured, time-limited free trial? Sign up now and start testing today!