Importance of Pacing & Think Time
Performance testing places a lot of emphasis on Think Time and Pacing. These phrases, which are used specifically while defining the workload during the workload modeling stage of the PTLC (Performance Test Life Cycle), are quite elementary. They differ significantly yet are both used to regulate the transaction rate during a load test. The difference between Think Time and pace is always unclear to a fresh performance tester. Here are brief explanations of each concept that help people comprehend Think Time and Pacing.
The virtual user (user thread) is instructed by think time to halt the business flow in between for the specified amount of time. To make things easier to understand, when a virtual user completes one transaction, it waits a while before beginning the next one. This accounts for the time a genuine user could pause (and consider) before doing another task on the website. The virtual user is told to wait the prescribed amount of time before beginning the subsequent business flow cycle (iteration) via pacing, in contrast. The virtual user sessions may be split out practically instantly since many performance testers neglect this testing capability. Given that there is always some time, this is not the wisest course of action.
Why Think Time?
To construct a real-world scenario, employ think time. The virtual user (user thread), as previously mentioned, is given the option to suspend the business flow when switching from one transaction to another. A user will never sign in, search, make a purchase, pay, and then log out in a short amount of time. He needs some time to reflect before acting. For a typical user, an average Think Time maybe 5 to 10 seconds. As a result, you should always include thinking time in your load tests to mimic real-world situations.
Achieving user concurrency on the server is a further justification for adding think time. The length of the user session on the server is extended by adding think time. Consequently, it aids in determining the concurrent user-handling capability of the server.
Why Pacing?
The rate at which requests are made to the server is controlled by pacing. Instead of merely blindly pummeling the server, pace to precisely reach the necessary load as per NFR. The actual load handling capacity of a server, expressed in TPS, is provided by proper pacing.
On the internet, there are two definitions of pacing. According to one definition, pacing is the total reaction time, thought time, and iteration delay. Pacing, according to another definition, is the interval between iterations. Any definition is acceptable, as long as it is used wisely in Little’s Law.
As per the first definition:
No. of Users = IPS x Pacing
where Pacing = End to End Response Time + Total Think Time + Delay between iterations
As per the second definition:
No. of Users = IPS x (End to End Response Time + Total Think Time + Pacing)
where Pacing = Delay between iterations
Example:
Let’s consider the below non-functional requirements:
No. of users = 6
No. of Transactions per iteration = 5
End to End Response Time = 25 seconds
IPS (Iterations per second) = 0.1
After creating the script add think time in between the transactions. Since there are 5 transactions so 4 think time functions (elements) need to be added. The think time value is decided as 5 seconds. Hence the virtual user will pause its flow for 5 seconds before starting the next transaction.
The total Think Time in an iteration will be 20 (= 5 + 5 + 5 + 5).
Now, we have the following metrics:
No. of users = 6
No. of Transactions per iteration = 5
End to End Response Time = 25 seconds
IPS (Iterations per second) = 0.1
Total Think Time = 20 seconds
Now, apply Little’s law:
No. of Users = IPS x (End to End Response Time + Total Think Time + Pacing)
- => 6 = 0.1 x (25 + 20 + Pacing)
- => 6 = 0.1 x (45 + Pacing)
- => Pacing = (6 / 0.1) – 45
- => Pacing = 60 – 45
- => Pacing = 15 seconds
Hence the delay between two iterations will be 15 seconds.
The illustration is as follows:
Another important point is Pacing is of two types.
- Constant Pacing
- Dynamic Pacing
To obtain precise TPS, dynamic pacing is usually advised. The rationale is that since iteration reaction time fluctuates constantly, using continuous pacing increases the likelihood of missing the desired TPS. The goal of dynamic pacing is to keep the TPS rate constant while attempting to minimize the effects of variations in reaction time. For ease of comprehension, the example above depicts continuous reaction time and tempo.
