In previous post I went through JMeter’s constant throughput timer (CTT) component usage and behaviour. Now, building on that knowledge I’ll show you some tips on how to make your life easier when using CTT.
Defining throughput variables in a separate component

Introducing throughput modifier

${__jexl3(${ThroughputModifier}*${AddNewClientsPerMinute})}

Adding ramp-up capability
The throughput modifier also enables an implementation of another useful feature which is a ramping up/down on throughput.
- slowly ramp up the load to the default target value
- ramp it beyond the target, e.g. when doing stress testing
- ramp down the load if needed
// definition of how the ramp-up should look like // e.g. starting with 10% of the target throughput, finishing at 100% (full target throughput), while doing 1% steps float start = 0.1; float end = 1; float step = 0.01; // computing how much time to spend (sleep) on each step float numberOfSleeps = (end - start) / step; int sleepDuration = rampUpDuration / (numberOfSleeps); // setting the throughput modifier property during the execution of the script, it will be picked up by CTT components // the correct interval between load increases is enforced by the sleep for (float i = start; i <= end; i = i + step) { props.put("ThroughputModifier", i.toString()); Thread.sleep(sleepDuration * 1000); }
OK, but where do you need to put the code in JMeter to be actually able to use this stuff?
I usually place the code in a separate thread group in either of:
- BeanShell/JSR223 sampler
or
- BeanShell/JSR223 pre-processor put as a child of a Test Action sampler
The thread group only fires up a single thread, that does one iteration of this code. And that’s it.
However, I always tend to add a bit of additional parameterization, to be able to set some of the variables from outside of the script. Let’s have a look at some more code, this time containing a few of props.get() methods :
// checking if I actually want to use this feature if (props.get("UseThroughputRampUp").equals("Y")) { int rampUpDuration = Integer.valueOf(props.get("ThroughputRampUpPeriod")); // Restricting ramp up duration (execution time of throughput ramp up thread group) to test duration if (rampUpDuration > Integer.valueOf(props.get("testDuration"))) { rampUpDuration = Integer.valueOf(props.get("testDuration")); } float start = Float.valueOf(props.get("ThroughputStartingValue")); float end = Float.valueOf(props.get("ThroughputLimit")); float step = Float.valueOf(props.get("ThroughputStep")); if ((end - start) > 0) { float numberOfSleeps = (end - start) / step; int sleepDuration = rampUpDuration / (numberOfSleeps + 1) * 1000; // computation and conversion to miliseconds for (float i = start; i <= end; i = i + step) { props.put("ThroughputModifier", i.toString()); Thread.sleep(sleepDuration); } } else { log.warn("Throughput ramp up will not be executed. Throughput limit should be greater than starting value of throughput); } }
Other stuff worth mentioning pertaining JMeter’s throughput topic
- JMeter plugins component called throughput shaping timer
- Beanshell server
I will go back and cover them in some future posts.
In some cases it may be worth using the Precise Throughput Timer (since JMeter 4). I haven’t used it in production yet, but it looks promising.
Hi Maciek, yes the Precise Throughput Timer (PTT) looks like a very nice alternative to Constant Throughput Timer (CTT), when you think of a “normal usage”.
The downside is that it doesn’t work if you pair it with the ThroughputModifier idea shown in the post 🙁 I tried it few months ago and it seemed to compute the pacing too rarely in comparison with CTT (which does it in every iteration).
Hence, for now, I stayed off using PTT for the ramp-up idea.