Performance Test Plan

performance Test Plan contains....

-Project requirements:
-functional requirements
-functionality of application
e.g. Login functionality
user should be able to login into application with valid username and password.if user enters invalid username/password , application has to give an error message

-non-functional requirements
-performance requirements
-Performance of application

e.g. how much time the user took to login into application

50 concurrent users login, time < 100 sec
100 concurrent users login, time < 200 sec

Types of test:
-load test:
-testing an application with requested no. of users.         The main objective is to check whether application can         sustain the no. of users with the time frame.

50 concurrent users login, time < 100 sec
100 concurrent users login, time < 200 sec

no. of users (vs) response time
    -stress test:
-testing an application with requested no. of users  over a time period. The main objective is to check             stability/reliability of application
-Capacity test:
-to check max. user load. How many users the application can sustain.

ramp up scenario

Components in loadrunner:
-virtual user generator
-Create ONE virtual user (vUser: simulation of real         user)
-record script
-enhancements:
-parametrization:
-test with more data sets
-check points
-to verify expected result
-correlation(regular expressions)
-to handle dynamic objects

-controller
-controller
-how many such users you need e.g. 50
-design load test scenario

-manual scenario
-no. of users (vs) response time
-no. of users is defined

-goal oriented scenario
-define a goal
- 20 hits per sec
- 10 transactions per sec

-run test scenario
-monitor test scenario
-generate dynamic graphs
-analysis
-prepare load test reports
-send it to project stake holders

example:

Client certificates in Truclient

When certificates are missing in TruClient ‘s Firefox, it is common to receive the following message during replay of the scripts, after which it fails

Certificate Error "Untrusted Connection…".

In such cases, the below procedure should resolve the problem:

Verify the security certificate is present in Firefox settings. Open the stand-alone Firefox installed on your system or the one in %vugen_path%\bin\firefox\firefox.exe.

Go to Tools > Options > Advanced > Encryption. The Certificate Manager window should appear.

Use the tabs to navigate through the certificate store that you would like to view. In case there are missing certificates, they need to be imported.

Close Firefox

Go to Firefox’ profile directory. On Windows 7 machines with stand alone Firefox installed the profiles are usually located in "C:\Users\Administrator\Appdata\Roaming\Mozilla\Firefox\Profiles\.default".

Copy key3.db and cert8.db to %vugen_path%\dat\LrwebToMasterProfile folder.

Create a new script.

This should overcome the Untrusted Connection message and allow the script to continue executing.

Ajax TruClient Protocol in Load Runner

To disable the popups from appearing:I tried a workaround with Loadrunner Ajax Click ans script Protocol to execute in Controller with out Ajax Click n Script License

Record a script with Ajax ClicknScript protocol. Then go to .usr file edit with notepad. You see below information No need to buy New Protocola license. 

[General]
Type=WebAjax
RecordedProtocol=WebAjax
DefaultCfg=default.cfg
AppName=
BuildTarget=
ParamRightBrace=}
ParamLeftBrace={
NewFunctionHeader=1
LastActiveAction=Action
CorrInfoReportDir=
LastResultDir=
DevelopTool=Vugen
Change the highlighted items in the above to below highlighted text. Then you can run your script successfully in the controller.

[General]
Type=Multi
AdditionalTypes=QTWeb
ActiveTypes=QTWeb
GenerateTypes=QTWeb
RecordedProtocols=
DefaultCfg=default.cfg
AppName=
BuildTarget=
ParamRightBrace=}
ParamLeftBrace={
NewFunctionHeader=1
LastActiveAction=vuser_init

1. In the url address field in Firefox, enter about:config.
2. Click the I’ll be careful, I promise! button.
3. In the Filter field, enter disable_open_during_load.
4. Right click disable_open_during_load and select Toggle. This changes the value to false.
5. Try to record the initial navigation step again.

Error: “Error -27279: Internal Error – Report initialization failed, error code=-2147467259 (0×80004005)” when replaying a script in VuGen on an ALM Performance Center Host

When replaying a Web (HTTP/HTML) script in VuGen 11.51 on an ALM Performance Center (PC) Host, the following error message is displayed at the beginning of the replay log:

Error -27279: Internal Error – Report initialization failed, error code=-2147467259 (0×80004005)

The script replay then continues normally and finishes successfully. However, when trying to view the replay results from the Replay -> Test Results… menu, a blank window opens and the results are not displayed.

During installation of the ALM PC Host the "logger.dll" DLL file was not registered.

Follow these steps to register the DLL file:

Ø Navigate to the command prompt launch file, e.g. C:\Windows\system32\cmd.exe

Ø Start the command prompt as Administrator, i.e. right-click on cmd.exe and select "Run as Administrator"

Ø Navigate to the bin folder in the ALM PC Host installation folder, e.g. "\bin"

Ø Execute the following command:

regsvr32 logger.dll

Ø Replay the script again

Error -26547: Authentication required, please use web_set_user in LoadRunner

Action.c(12): Error -26547: Authentication required, please use web_set_user, e.g. web_set_user("domain\\user", "password", "host:port"); [MsgId: MERR-26547]

After adding the web_set_user() as suggested in the error message a further error is received:

Error -26630: HTTP Status-Code=401 (Access Denied) for "http://" [MsgId: MERR-26630]

LoadRunner does not currently support Microsoft Distributed Password Authentication (DPA)

To determine if DPA is being used in the generation log look at the header in the Server response to the initial GET. The following is an example server response:

HTTP/1.1 401 Access Denied\r\n

Server: Microsoft-IIS/5.0\r\n

Date: Fri, 15 Jan 2010 11:07:04 GMT\r\n

WWW-Authenticate: DPA\r\n

Content-Type: text/html\r\n

Cache-Control: proxy-revalidate\r\n

Content-length: 616\r\n

Proxy-Connection: Keep-Alive\r\n

Connection: Keep-Alive\r\n

Proxy-support: Session-based-authentication\r\n

Note the WWW-Authenticate:DPA

There is currently no workaround available

After adding a permanent license in LoadRunner 11.50 the Controller crashes when it is opened

When adding a permanent license in Load Runner 11.50 License Utility the license is displayed correctly. However, when opening the Controller it crashes silently and it is not possible to use it.

The length of one or more of the license keys applied in the License Utility is too big and the Controller is not able to handle it correctly.

The issue is resolved in LoadRunner Service Pack 11.51.

Try the following:

1. Open Windows Explorer and navigate to “%AllUsersProfile%\Application Data\HP\LoadRunner\data",
2. Open file LRKey.txt and then 
3. Remove the content in double quotes ("") in all occurrences in the file and save the changes. These are the license key descriptions. Removing them makes the keys shorter,
4. Finally Open the Controller.

License Manager was not initialized

In the Controller when running a test if the following error is shown : Error Message "License Manager was not initialized"

The reason for this error to occur is because the user account doesn’t have the required permissions to initialize the LoadRunner libraries and interact with the operative system.

Be sure that you are using a full Administrator account over the machine where the Controller is installed. Any other permissions group will affect the load test.

Completely disable the DEP and reboot the machine.

Open an Elevated Command Prompt

i. Open the Start Menu

ii. Click All Programs and Accessories

iii. Right click on Command Prompt and click Run as Administrator

iv. Click on Continue

To Disable DEP

i. In the Elevated Command Prompt, type:

bcdedit.exe /set {current} nx AlwaysOff

ii. Restart the computer to apply

VuGen does not launch any applications while recording

Turn off Data Execution Prevention in Windows

If this problem occurs with every application that it tries to launch, make sure Data Execution Prevention is turned off. To find Data Execution Prevention:

1. Right-click on My Computer, and choosing Properties.
2. Select the Advanced tab, and click on Performance, then Settings.
3. Select the Data Execution Prevention tab, and make sure the first option is selected which is “Turn on DEP for essential Windows programs and services only.

What is the relation between Response Time and Throughput?

The Throughput graph shows the amount of data in bytes that the Vusers received from the server in a second. When we compare this with the transaction response time, we will notice that as throughput decreased, the response time also decreased. Similarly, the peak throughput and highest response time would occur approximately at the same time.

How did you plan the Load? What are the Criteria?

Load test is planned to decide the number of users, what kind of machines we are going to use and from where they are run. It is based on 2 important documents, Task Distribution Diagram and Transaction profile. Task Distribution Diagram gives us the information on number of users for a particular transaction and the time of the load. The peak usage and off-usage are decided from this Diagram. Transaction profile gives us the information about the transactions name and their priority levels with regard to the scenario we are deciding.

Understanding Mean Time Before Failure (MTBF) in Performance Testing

Introduction:

In performance testing, Mean Time Before Failure (MTBF) is a crucial metric used to evaluate system reliability and stability under load. This post explores how to create a scenario to determine MTBF and analyze the results using a practical example.

Scenario Setup:

Let's consider a scenario where we are testing the performance of an airline booking system. Our goal is to determine the system's MTBF by gradually increasing the load until we observe a critical failure point.

Test Steps:

1. Identify Critical Transactions: Begin by identifying critical transactions in the application, such as searching for flight itineraries or booking tickets. These transactions represent key functionalities that users commonly perform.
2. Define Load Profile: Determine the load profile for the test, including the number of virtual users (Vusers) and the ramp-up period. Start with a low number of Vusers and gradually increase the load over time.
3. Execute Load Test: Execute the load test scenario using a performance testing tool like LoadRunner or JMeter. Monitor key performance metrics such as response time, throughput, and error rates.
4. Analyze Results: Analyze the test results to identify patterns and trends. Look for indicators of system stress, such as a sudden increase in response time or a spike in error rates.

Detailed Analysis:

• Response Time vs. Vusers Graph: Plot a graph of response time against the number of Vusers. Observe how the response time behaves as the load increases. Look for any sudden spikes or significant increases in response time, indicating potential system stress or failure points.
• MTBF Calculation: While MTBF is traditionally calculated based on historical data, in performance testing, it can be inferred from the test results. Identify the point at which the system's response time sharply increases or exceeds acceptable thresholds. This critical point represents the MTBF, indicating the load at which the system begins to fail.
• Capacity Analysis: Determine if the observed failure point represents the system's maximum capacity or if it indicates a bottleneck in a specific transaction or component. Further testing may be required to validate the system's maximum capacity under different scenarios.

Conclusion:

Mean Time Before Failure (MTBF) is a vital metric in performance testing, providing insights into system reliability and performance under load. By creating a scenario to determine MTBF and analyzing the results, testers can identify critical failure points and optimize system performance for enhanced reliability and user experience.

How many types of graphs does LoadRunner have?

LoadRunner has in total 5 different types of flag which are as follows:
The Hits per second graph that depicts the traffic volume of the application being tested for.
Pages download per second graph shows the rate at which the download processes are carried out at a particular instance of time.
The Transaction response time (load )
The Transaction response time (percentile) graph
Network delay time graph shows the time elapsed for the request/ response activities in the application.

What is injector in LoadRunner?

Injectors can also be called as load generators in LoadRunner. In order to create multiple Vuser script it is essential to create a scenario where the load generator has to be specified first. This provides vital host information such as it is local or remote host. The load generators must add the IP addresses of the participating machines from where the Vusers are assimilated to run scripts but prior to that the load generator must be installed in them as they are to be used as injectors

what is pacing?

Pacing is also like a wait but it is used to time count between two iteration.

Pacing is nothing but scheduling the next iteration.It consist of options:

1.as soon as previous iteration

2.start iteration with delay

Embedding Pacing In Load Runner Scripts | Pacing For Blocks in Load Runner

In LoadRunner scripts, pacing logic is often crucial for controlling the flow of iterations. However, when Action blocks are involved and recalculating pacing time after each iteration becomes necessary, a different approach is needed. Let's explore a dynamic pacing logic that adjusts pacing time based on the test duration left.

This pacing logic consists of three distinct functions embedded in a .C function file:

1. InitCore()

2. TopOfIterations()

3. BottomOfIterations()

1. InitCore():

The `InitCore()` function initializes the core parameters required for dynamic pacing. It takes three parameters:

Syntax: InitCore(TestDuration (in Seconds), TotalBlockIterations, MaxNumberOfIterations);

Example: InitCore(180, 12, 2);` - The script will execute for 24 iterations and for 180 seconds (i.e., 3 minutes).

2. TopOfIterations():

The `TopOfIterations()` function calculates the initial pacing time based on the test duration and total number of iterations. This function call should be placed at the beginning of the main Action block.

3. BottomOfIterations():

The `BottomOfIterations()` function recalculates the pacing time after the completion of each block execution, considering the remaining test duration and iterations. This ensures dynamic adjustment of pacing time instead of using a fixed value. Note that each block execution is treated as an iteration. 

This function call should be placed at the end of the main Action block.

double TestDuration, pacing_time, Origpacing_time;

int Counter = 1, MaxCounter = 0, TotalIterations;

merc_timer_handle_t timer;

double duration;

InitCore(double TDuration, int TotalBlockIterations, int MaxNumberOfIterations)

{

    TestDuration = TDuration;

    TotalIterations = TotalBlockIterations * MaxNumberOfIterations;

}

TopOfIterations()

{

    if (Counter == 1) {

        lr_output_message("Action1 - Total Test Durations - First Time: %lf", TestDuration);

        pacing_time = (double)TestDuration / TotalIterations;

        lr_output_message("Action1 - Total Iterations Left - First Time: %d", TotalIterations);

        lr_output_message("Action1 - Pacing - First Time: %lf ", pacing_time);

    }

}

BottomOfIterations()

{

    if (duration <> 0) {

        TestDuration = TestDuration - pacing_time; //Is equal to Pacing time

        MaxCounter = 1;

    }

    TotalIterations = TotalIterations - 1;

    if (MaxCounter != 0) {

        lr_think_time(pacing_time - duration);

        pacing_time = TestDuration / TotalIterations;

        MaxCounter = 0;

    }

    else if (TestDuration > 0) {

        TestDuration = TestDuration - duration;

        pacing_time = TestDuration / TotalIterations;

    }

    if (TestDuration <= 0) {

        pacing_time = 0;

    }

    lr_output_message("Action1 - Total Iterations Left: %d", TotalIterations);

    lr_output_message("Action1 - Total Test Durations Left: %lf", TestDuration);

    lr_output_message("Action1 - New Pacing: %lf", pacing_time);

    Counter = 0;

}

Happy Testing !

Calculating Processor(_Total)\%Processor Time For System Using Process(*)\%Processor Time Performance Counter

Before going to detailed description on this topic, I would like to start it with a question...!!!!"Can we calculate %Processor Time for the System which has multi-core processor if Processor(_Total)\%Processor Time counter is not included in the Perfmon?" [Also, provided we have all the necessary counters for the Process Object in the Perfmon, for e.g. Process(*)\%Processor Time is included]

Any Guess...!!!!!

Let me tell you how we can do this using the Process(*)\%Processor Time counters for the Process Object.

We can do this by using the following formula which will reflect exactly the same values for the Processor Counter [i.e. Processor(_Total)\%Processor Time]

Use the below formula:

Processor(_Total)\%Processor Time =[Process(_Total)\% Processor Time - Process(Idle)\% Processor Time]/Number Of Cores

Considering Process(_Total)\% Processor Time = Number_Of_Cores * 100

Bit confusing..????

Let me explain you with some example which will give you more understanding on this measurement.

Consider the below raw data which I have from the Perfmon utility every 1 second. I have considered here only 3 performance counters to make you understand:

1. Process(_Total)\% Processor Time

2. Process(Idle)\% Processor Time

3. Processor(_Total)\% Processor Time

Process(_Total)\ % Processor Time  Process(Idle)\ % Processor Time

194.7602101 113.7708158

199.68128 174.72112

196.5612 170.04109

198.12127 174.72112

Processor(_Total)\% Processor Time

43.11458591

12.63944

14.97946

12.63944

Descriptions:

I have a Dual-Core machine, so let me consider the column \\MachineName\Process(_Total)\% Processor Time to evaluate it's values as:

\\MachineName\Process(_Total)\% Processor Time = 2 x 100 = 200 [So we can consider column values of this counter as 200 instead of 194.7602101, 199.68128 and so (this is nothing but the value 100% for each cores).

So, now let me calculate the Processor(_Total)\% Processor Time with the available Process related data.

e.g.

Processor(_Total)\% Processor Time = [200 - 113.7708158]/2

= 43.1145921 (which is almost equal to what it is shown in the third column of the Perfmon result i.e. equal to column values MachineName\Processor(_Total)\% Processor Time)

This explains the procedure to calculate the Processor(_Total)\% Processor Time if in case only Process counters are included in the Perfmon Utility.

Monitoring System Resources On Remote Machines Using PERFMON

We use to monitor the system resources using PERFMON and our machines without any issues, but I faced some different kind of issues while monitoring the remote machines using PERFMON tool from a centralized machine.

Before going into the detail of the PERFMON issues, please ensure few things on your machine where you are going to start the counter logs.

a) Check that Performance Logs and Alerts service is running

b) The service name is SysmonLog and the path to executable is "C:\window\system32\smlogsvc.exe". This service should be running in the services window.

I had 8 machines configured on the same domain and wanted to monitor these machine from a single point centralized machine. The required counters were created using "logman Create" method and to start and stop these perfmon counters I used to have a batch file. (This will monitor system resources on all the 8 machines from the centralized machine.

Now here comes the problem....!!!!

When I started the counter logs, it didn't start collecting data from these 8 machines. The reason for this is that, the user (for this centralized machine) doesn't have access to these machines so the perfmon counter logs were not getting started on these machines and hence the data is not collected.

The solution for this issue is that, after creating the counter logs on the centralized machine to monitor system resources of remote machines, perform the following actions:

1. Open Perfmon window

2. Go to properties of the counter logs (that has been created to monitor the remote machines)

3. On the System Overview properties (in XP, will be different in higher version of OS), type the User Name in the "Run As:" field and click on either "Set Password" or "Change" button (based on the OS version you are using)

4. On the Set Password window, provide the User Name, Password and Confirm Password and click on OK Button

Now, you are all set to monitor the system resources of the remote machine from a centralized machine.

Difference In Monitoring System Resources From Performance Center & Controller

You might have monitored system resources from HP Performance Center or HP LoadRunner Controller application. But any time did you have faced any problem while collecting data (like %Processor Time, pages/sec etc for memory etc).
There is difference in adding measurements from Performance Center & from Controller. Have you ever seen that when you add System IP for collecting data from this IP while executing your scenario, but the data is not collected. I have faced this problem. Let me explain my scenario in this case:
In Performance Center:
1. You create a scenario, add scripts to execute in Design tabs and add the monitors in the Monitors tab (you provide the UserID/Password while adding the performance counters to be monitored on the machine).
2. You start the scenario, and the performance data is collected from this machine.

But do you really think it is so simple if you add performance counters for a machine on HP LoadRunner Controller.
Try adding the performance counter in LoadRunner Controller scenario and start the scenario. You will see that the window resources graph doesn't display the data. (it has happened with me) .
This is due to the fact that, while adding the machine under window resources, it doesn't ask for the system UserID/Password and the LoadRunner Controller machine UserID/Password overrides the UserID/Password of the system which is to be monitored.

So in this case, the password of the Controller machine and the Monitor machine should be same. Then only you can monitor the system resources added in the Controller scenario.

Performance tuning

Let us have some information about tuning concept to be introduced during performance testing. In my scenario, the number of users were supported by the application was only 18. Beyond this number all users were failing to logging with the "Database Related Error". The error that I was getting was "Couldn't create Database Instance". [looks like it is a Database related error]
When I started looking into this issue, we had few areas that we could look for the solution. They were:
1. Connection Pools
2. Tomcat (if tomcat is the Web Server)
3. OS system file
4. Hardware resources

I encountered this issue on Solaris box. I started finding the solution for this issue and below are areas I looked into:

1. I started looking at the Application Server Connection pools issue. We had few parameters in the web.xml file under the middle-tier where min_connex and max_connex parameter was defined related to the Database. These parameters were set to 2 and 5 respectively. The best way to start finding the solutions for any issue is the log that is being written. In the middle-tier log, out of 4, 3 connection pools were always idle. So, there was no problem at the middle-tier side.

2. I tried increasing the tomcat memory from 512MB to 1024MB in catalina.sh file. This didn't resolve the issue.

3. Looked into the /etc/System file on the Solaris OS and saw some parameters like maxusers, maxuproc (maximum user processes). Setting maxusers to a value will control max_nprocs and maxuprc. The algorithms are:
max_nprocs = 10 + (16 x maxusers)
maxuprc = max_nprocs – reserved_procs (default is 5)
Even this setting didn't resolve the issue.

4. last but not the least, I looked into the System resources and found that the root path (i.e. "/") doesn't have much disk space to allocate DB resources any more beyond 18 users. Since the Oracle was setup at "/" path and the Oracle folder wasn't assigned any more system resources, Oracle was utilizing the space allocated to "/". Due to in-sufficient disk space on "/" path, users were not able to make connection with the Oracle DB and hence was failing.
Increasing the root disk space eliminated the issue with the user login.

Hope this was a good article to understand the tuning concept applied before looking into in details of performance tuning.

VUSER CALCULATIONS ?

Calculating How Many Maximum Number Of Users Required If We Need To Achieve 12K Transactions With SLA Of 5 Minutes

Total Number of Transactions to be completed = 12,000
Average Response Time = 5 Minutes

To avoid putting much load on the system I will add 5 Minutes so that to total time taken to complete one iteration will be 10 Minutes. This addition will include the thinktime between the each screen/transaction traverse.

Now, I know each iteration will take 10 Minutes to complete, hence in 60 Minutes only 6 transactions can be completed. i.e. 1 User will do 6 transactions in an hour.

Now how to calculate how many users are required to complete 12,000 transactions in an hour?
The calculation will be:
#Users Required = 12,000/6
= 2000 Users

This way we can find the number of users required if total throughput is provided with an average response time.

Hence to achieve 12,000 transactions I need 2000 Users with 5 minutes of thinktime in between the iterations with an average response time of 5 Minutes.

Hope this post helps you to come-up with a Workload Modelling Concept (a bit). Please do let me know if my assumptions are wrong.

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.