Pacing Technique (Part 1)

The purpose of this entry is to describe a technique for specifying the arrival rate of users in a web application. Note: In English, pacing is known as “pacing,” which we will use in this article.

What is Pacing? #

Pacing refers to the interval between visits to an Internet application. Pacing represents the number of test scenarios that occur in a certain period of time. Note: See my colleague Antonio’s blog for an excellent explanation of test scenarios.

Similarly, Pacing represents a requirement in the sense that Pacing defines the objective (in terms of hourly visits, for example) that an application is expected to support. In other words, it is a acceptance criterion of the load test results (another acceptance criterion could be response times, for example).

Including Pacing in a Test Allows for Regular Rhythm of Arrival at the Application and Thus Precisely Reach the Desired Load. As a Consequence, This Allows Determining the Capacity of Load that the Application Can Accept or Support.

Finally, it is important to mention that this technique applies to applications of the type open models where visits to the application arrive independently (asynchronously). Said with a side note, this is the characteristic that most of the workloads that occur in the Internet have (for example, e-commerce).

The Technique Using the Arrivals Threads Group #

There are several techniques for implementing Pacing in JMeter, but this article focuses on one based on the Arrivals Thread Group. What makes this TG important is that it maintains the load (workload) by creating threads/vusers as necessary.

We demonstrate how it works using a simple example. In this example, the client requires that the application support 240 visits/minute. Working with the client, we design what constitutes a visit or session:

As shown by this chart, the session is composed of four steps (implemented using a Dummy Sampler). Each step is assigned a Response Time, and for the last three steps, a constant ThinkTime of 2 seconds respectively. Additionally, we use 3 listeners to help us analyze the results.

The following diagram illustrates the configuration of the Arrivals Threads Group. Since the pacing requirement is 240 visits per minute, we have entered this amount in the area labeled Target Rate (arrivals/min). Additionally, we have entered the duration of the test at 30 minutes into the area labeled Hold Target Rate Time (min).

• Important Note: Pacing applies to the entire session, and as a consequence to each step (requests) of the scenario.

Result and Analysis #

Upon completion of the test, the Aggregate Report listener displays the following results:

First, we observe that the number of executions for each step (samples) is approximately 7,200. Dividing this number by 30 (the duration in minutes), the result is 240 executions per minute. This is the requirement for the test!

As we mentioned at the beginning, the Arrivals TG generates the Threads/VUsers needed to maintain the load. To determine this number, we can use the plugin Active Threads Over Time in this way:

According to the graph, the approximate number of VUsers is around 64. Alternatively, the VUsers (active users) are calculated using one of the laws of Queue Theory, Little’s Law.

# active users = active users + paused users (ThinkTime)

# active users = (Throughput average * Response time average) + (Throughput average * Think time average)`

# active users = 15.9 * 2.5 + 15.9 * 1.5 = 63.60

Conclusion #

Although the Arrivals Threads Group is intuitive and relatively easy to configure, it has some limitations: users arrive at a constant rate, which is not realistic given that web arrivals are completely arbitrary/random. Additionally, estimating the number of active users (vusers) is not a direct process.