How to Easily Implement Pacing in JMeter

What is Pacing in Load Testing and Why is it Important?

Pacing in load testing refers to the time between the iterations of your test scenarios. This is unlike Think Time, which refers to the delay between actions or interactions inside iterations.

Pacing allows the load test to better simulate the time gap between two sessions. In reality, the same user will not instantaneously go to the next iteration, so this wait time between sessions will create a more realistic load on your application.

By using pacing in your test, you will be able to regulate the rate of requests that hit your application and accurately achieve a desired load. This will allow you find out the exact load capacity your application can handle.

To implement pacing in Apache JMeter™, we can use either use Groovy Scripting or one of these two timers: the Constant Throughput Timer or the Throughput Shaping Timer.

Implementing Pacing with Groovy Scripting

If you want to have more customization over how your pacing timer works, you can do so by using Groovy scripting.  The reason we want to use Groovy here, is that it has excellent execution performance. This allows for it to be used during more extensive load testing, without requiring a lot of resources. Then, you will be able to run larger load tests, while minimizing your machine’s resource usage.

This method will make use of the Test Action sampler and a JSR223 Timer that uses Groovy scripting to calculate the pacing. The Test Action sampler is there to create a pause after what comes before it runs. However, we don’t want to use a constant value for pacing as this will not be adjustable for the response times of the test. This is why we need the Groovy script - to calculate the difference between our desired rate of time for each scenario.

First, we will need to create the scenario for this test. This scenario is the iteration after which we will set the pacing. In this scenario, 10 users will run simultaneously for 5 minutes going to the blazedemo.com home page and then to the reserve page.

1. Create a thread group by Right Clicking “Test Plan” -> Add -> Threads (Users) -> Thread Group.

Here we will define the “Number of Threads (users) = 10”, “Ramp-Up Period (in seconds) = 10”, “Loop Count = Forever (mark the checkbox)”, mark the “Scheduler” checkbox, and set the “Duration (seconds)” = 300. Also, rename the Thread Group to “Pacing Timer Example”.

2. Create a HTTP Request Defaults config element by Right Clicking “Pacing Timer Example” -> Add -> Config Element -> HTTP Request Defaults.

Here we will define the “Server Name or IP = blazedemo.com” and rename the element to “Blazedemo”.

3. Create a Simple Controller by Right Clicking “Pacing Timer Example” -> Add -> Logic Controller -> Simple Controller.

Here we will name the controller as “MyScenario”.

4. Create two HTTP Requests by Right Clicking “MyScenario” -> Add -> Sampler -> HTTP Request.

One HTTP Request will be renamed “Blazedemo Home” while defining the “Method = GET” and the “Path = /”.

The other HTTP Request will be renamed to “Blazedemo Reserve” while defining the “Method = POST”, the “Path = /reserve.php”, and adding two parameters, “fromPort” and “toPort”, with the value for each being “Paris” and “Buenos Aires, respectively.

5. Create a Constant Timer for each request by Right Clicking the HTTP Request -> Add -> Timer -> Constant Timer.

Define the “Thread Delay = 400” for each timer and rename them “Think Time.”

6. Add an Aggregate Report listener by Right Clicking “Pacing Timer Example” -> Add -> Listener -> Aggregate Report. This will show you the throughput of each request and allow you to see that the request rate is very close to even.

Now, we need to build the the Groovy Script Pacing Timer.

7. Right Click on “MyScenario” -> Add -> Sampler -> Test Action.

Rename the Test Action to “Pacing Timer”, set “Duration (milliseconds) = ${myDelay}” and leave the “Target” as “Current Thread” and the “Action” as “Pause”. The ${myDelay} variable will be received from the Groovy script, based on the response times of the entire scenario. The “Target” set as “Current Thread” will have the Test Action affect each user, instead of all users at the same time. The “Action” set to “Pause” will pause the test for the allotted time provided by the Groovy scripting timer.

8. Right Click on “Pacing Timer” -> Add -> Timer -> JSR223 Timer.

Rename the timer to “Pacing Timer”, set the “Language = groovy”, which is pre- installed for JMeter version 3.2, mark the “Cache compiled script if available” checkbox, which compiles and caches the script allowing for a significant increase in performance, and insert the following script into the window:

//Sets the pacing length based on the last requests response time. 4500 is the time in msLongpacing=4500-prev.getTime();//If the response time is less than 4500 ms, set the delay value to myDelayif(pacing>0){//iPacing is equal to the int value of pacing if pacing is not equal to null, otherwise iPacing is nullIntegeriPacing=pacing!=null?pacing.intValue():null;log.info(String.valueOf(iPacing));vars.put("myDelay",String.valueOf(iPacing));returniPacing;}//The response time is greater than or equal to 4500 ms, set myDelay to 0else{vars.put("myDelay","0");return0;}

What this script does is it actively calculates the amount of time the iteration needs to wait in order to maintain a pace of 4500 ms, or 4.5 seconds, per scenario. If the scenario runs over the 4.5 seconds, then a pacing time is not required, as we want to keep our request rate as constant as possible, hence we want to start the next iteration.

You have successfully created a pacing timer using Groovy! When you run the test, you will notice that the throughput for your scenario is about 2 RPS, which you can see in the Aggregate Report below:

If you want to adjust the number of requests, you can adjust the 4500 number, which is the time in milliseconds, to make the delay shorter or longer, based on your needs. When creating pacing timers using Groovy, it is always best to make sure that the pacing time you set is not exceeded very often, as this will cause your iterations to occur one right after another negating the purpose of the pacing timer, which is to achieve a constant request rate.

The goal is to dynamically adjust the time between iterations based on the response times of your entire scenario in order to keep your request rate constant, allow for your application to “breathe” between iterations of your scenario for each thread.

A normal user will not just immediately go through your scenario over and over again without taking some type of break in between iterations.

For example, if you want an iteration to occur every 10 seconds, then the wait times would be calculated as such:

• If iteration 1 takes 5 seconds, then the wait time will be 10 sec - 5 sec = 5 seconds.
• If iteration 2 takes 8 seconds, then the wait time will be 10 sec - 8 sec = 2 seconds.
• If iteration 3 take 11 seconds, then the wait time will be 10 sec - 11 sec = 0 (no negative values)

This is the basic logic behind the pacing timer shown above, but with different values in the response times and pacing times.

Implementing Pacing with JMeter Timers

As of JMeter version 3.2, all  types of timers can be used to regulate the amount of requests made over a period time, but there are two that directly regulate your request rate.  These timers are the Constant Throughput Timer, which allows you to regulate the amount of requests per minute and the Throughput Shaping Timer, which allows you to regulate the amount of requests per second and allows you to configure multiple asymmetrical RPS scenarios.

The Constant Throughput Timer comes standard with JMeter, while the Throughput Shaping Timer is a JMeter plugin, which you can get through the Plugins Manager. We will use the same scenario we used for the Groovy scripting section.

Implementing Pacing with the Constant Throughput Timer

Now that we have our scenario built, we can add a Constant Throughput Timer to control the pacing of our scenario. To do this, just do the following:

7. Right Click “Pacing Timer Example” Thread Group -> Add -> Timer -> Constant Throughput Timer.

Rename the timer to “Pacing Timer” and set the “Target throughput (in samples per minute) = 10” and leave the “Calculate Throughput based on = this thread only.” This will ensure that each thread (or user) can only send 10 requests per minute, for a total of 100 request per minute, as we defined our thread group to run 10 threads.

That’s it! You have added a pacing timer to your load test, which will limit the amount of requests JMeter makes and keep your request rate constant. With a the constant request rate, you will be able to achieve a desired load without needlessly hammering your application with numerous requests.

Now run this test and observe the Aggregate Report results and notice that each request will run at about 50 requests per minute and will not exceed 100 total requests per minute.

Implementing Pacing with the Throughput Shaping Timer

Using the same scenario above, we can do the same to control the requests per second (RPS) using the Throughput Shaping Timer. By controlling the amount of requests per second, we are essentially spacing out the iterations of the test, allowing for rest periods between iterations of the scenario.

To add this timer, do the following:

7. First, ensure that you have the plugin installed using either the Plugin Manager, or by downloading the JAR from this link and inserting it into the /lib/ext folder within your JMeter folder. Next, follow the steps below to create the timer:

8. Right Click “Pacing Timer Example” Thread Group -> Add -> Timer -> jp@gc - Throughput Shaping Timer.

Click the “Add Row” button, which will add a row with values for “Start RPS,” “End RPS,” and “Duration, sec.” Change the values to “Start RPS = 10” ,”End RPS = 10”, and “Duration, sec = 300” and rename the timer to “Pacing Timer.”

You have now created a pacing timer using the Throughput Shaping Timer! When you run the test, you will notice that the Throughput in the Aggregate Report will show each request running about the same amount of RPS, and the total RPS will be very close to 10.

In conclusion, pacing timers are used to better simulate the wait times a user takes between each iteration of your scenario.  By following the steps above, you will be able to implement pacing in JMeter using timers or through Groovy scripting.

Get the most out of all your JMeter tests with the industry's most-trusted performance testing platform. Start testing with BlazeMeter for free today!

Start Testing Now