PACING Calculation | Pacing Calculator

Pacing Calculation Formula Overview:

In the context of our discussion, let:

• D be the Duration of the test (test window/time frame).
• B represent the Baseline time (total time taken by 1 Virtual User to complete 1 whole iteration).
• T denote the Total amount of Think time in the script.
• I be the Expected/Target iteration.
• R represent the Residual time of the test window.

The residual time R can be calculated as:

$�=(�-(�+�)\times �)$

And the Pacing interval P can be determined by dividing the residual time by the target iteration:

$�=\frac{�}{�}$

Hence, $�$ represents the pacing time, $(�+�)\times �$ signifies the duration of a scenario, and $�$ denotes the waiting time before the next scenario.

Example 1: Calculating Pacing Time/Think Time:

Let's aim to achieve 50 Transactions Per Second (TPS) with an average response time of 0.5 seconds using 100 Users. Here's how we calculate it:

1. Total Transactions in an Hour: $1\text{ sec}=50\text{ transactions}$ $3600\text{ sec}=�$ Thus, $�=3600\times 50=180,000$ transactions/hour by 100 Users.

2. 
   

3. Transactions per User: Total Users = 100 Each User will perform $\frac{180,000}{100}=1800$ transactions/hour.

4. 
   

5. Think Time Calculation: Given each transaction takes 0.5 seconds on average, Total time to complete 1800 transactions = $1800\times 0.5=15$ minutes. Thus, 45 minutes of think time is needed between 1800 transactions (i.e., $45\times 60=2700$ seconds of think time per user). $2700$ seconds = 1800 transactions, which implies $�=1$ transaction. Therefore, $�=1.5$ seconds of think time need to be included.

6. 
   

7. Total Iteration Time: Total time required for each iteration = $�+0.5$ seconds $=1.5+0.5=2$ seconds.

Verification:

Total time = $1800\times 2=3600$ seconds = 1 Hr Thus, each User will perform 1800 transactions within 1 hour, with 2 seconds provided for each iteration to complete.

Random Virtual User Pacing in LoadRunner:

LoadRunner's random Virtual User (VU) pacing feature offers flexibility in simulating real-world scenarios. Here's a practical example of how it can be applied:

Consider a project requiring LoadRunner's random VU pacing for the first time to meet specific performance requirements.

Approach:

1. Project Documentation: The project provides comprehensive documentation, including system specs, API guides, and performance requirements such as production volume reports and capacity models.

2. 
   

3. Capacity Models: Capacity models estimate maximum transaction load per hour and per minute (max TPM). To maintain an average TPM while randomly reaching the max TPM, pacing needs to be adjusted dynamically.

4. 
   

5. Calculation: For instance, if the maximum hourly transaction rate is 720 requests and max TPM is 20, the average TPM would be $\frac{720}{60}=12$. The goal is to vary the pacing to fluctuate between 4TPM and 20TPM, averaging around 12TPM.

   • Example Calculation:

     • To achieve 12TPM with transactions taking 1-2 seconds, a pacing of around 120 seconds is needed. For a fixed load of 12TPM with a 5-second Ramp-up and 24 users, the pacing is set to 120 seconds.
     • 
       

   • Modifying Pacing:

     • To vary the TPM to $�$ with the same 24 virtual users, pacing should be adjusted to $\frac{24\times 60}{�}$.
     • 
       

   • Verification:

     • By generating pacing values within a range, LoadRunner's random function can simulate varying TPM. Adjustments may be needed to align pacing ranges with desired TPM averages.

Note:

1. P=(I−1)R​:

   • This formula calculates the pacing interval by dividing the residual time by the number of intervals (iterations) between transactions. It assumes that pacing is needed between each iteration except for the last one. This approach is suitable when you want to ensure a consistent pacing interval between transactions, excluding the final one.
   • 
     

2. $�=\frac{�}{�}$:

   • This formula calculates the pacing interval by dividing the residual time by the total number of iterations. It includes pacing after the last iteration as well. This approach may be appropriate if you want to ensure pacing throughout the entire test duration, including after the final iteration.