Category: Testing Tools

Issue: “communication between vugen and the truclient browser could not be established”. This error occurs when we click the ‘Develop Script’ button.

Solution: Simple step, Run the Vugen.exe as ‘Administrator’.


IP Spoofing in Loadrunner

IP Spoofing

It is a technique used for creating Internet Protocol (IP) packets with a forged source IP address, with the purpose of hiding the identity of the sender address.

IP Spoofing in Loadrunner

This technique is used in Loadrunner Agent machines, in order to make the Application server to think requests are coming from different machines. This purposely used in the Load Balancing Application servers which runs on the IP based distribution.

Procedures to configure the IP Spoofing in Loadrunner

Step 01: Get the required number of static IPs (based on number of vusers to be executed) from the Network Administrator, which should have the same ‘Default gateway’ of the LG machine.

Step 02: Follow the IP wizard in the LG machine and do the setup by adding the required number of Static IPs.

Step 03: After finishing the configuration setup, try pinging one of the static IP. It should not get ‘Timed Out’ error.

Step 04: Now we are ready to do the execution with Controller. While creating the scenario, enable the ‘IP Spoofing’ option in the LG machine.

This should work. If any issues, comment to reach me. Thanks.

Inorder to start scripting the SAP applications using the Loadrunner tool, we have to enable the scripting mode available in the SAP application apart from the normal script enabling setting.

Please use the TCode – RZ11

Navigate to the page it allows and change the settings to ‘FALSE’ for the below mentioned parameters.

a. sapgui/user_scripting_set_readonly and set the value as “FALSE”
b. sapgui/user_scripting_force_notification and set the value as “FALSE”


In Loadrunner script, we use block size per vuser for using the huge range of unique values in a parameter. But during the test, if the execution failes inbetween its very hard to re-allocate the block size again by checking the unused values. In-order to solve this issue, we can use the LR_ADVANCE_PARAM function in loadrunner. Please find below the usage format to implement this.

int x,y,v,i;  // declare these variables as integer
v=atoi(lr_eval_string(“{VuserID}”));  // get the VuserID and store it in v
i=atoi(lr_eval_string(“{ItNum}”));  // get the Iteration number and store it in i
 x=v;  // For the first iteration, x = VuserID
 x=6;  // For the second iterations onward, x = No of Vusers  + 1 (assuming Vusers = 5)
lr_advance_param(“CreatedCustID”);  // parameter file name (keep settings as Sequential Once)



return 0;

The purpose of a firewall is to increase security by blocking communications and allowing communications with only certain ports, such as 80 and 443 for HTTP and HTTPS traffic.
By default, the LoadRunner Controller uses TCP port 50500 to send data to TCP port 54345 on the Windows Load Generator.
The Load Generator sends information back via a dynamic port, through the MI Listener.
To avoid having to beg Network Administrators for more ports to be opened, on each load generator machine inside the firewall, from

Start > Programs > LoadRunner > Advanced Settings > Agent Configuration (launch_service\bin\AgentConfig.exe)

install the (Monitoring Over Firewall machine) MoFW/RoWF agent.

Check the option “Enable Firewall Agent”.  It collects performance counters and sends them to a controller over a firewall. MoFW communicates with the MI Listener through port 443, so you can’t have any web servers (like Apache WebTours, IIS, or Oracle HTTP servers) running on both the machines.
Verify whether port 443 actually allows communication by running command and substituting the ip address in:
telnet 443
This should open a telnet window.

UNIX Load Generator uses a dynamic port that cannot be fixed.
When defining a “remote” load generator from within the Controller, click “Details” for the “Load Generator Information” dialog, where you can click the “Firewall” tab and check “Enable Firewall”.
Courtesy :

char newvalue[15]=”I Love India”;

long pfile;

char *filename = “C:\\Sample.txt”;

pfile = fopen( filename,”a+” );

if(pfile == NULL)


printf( “Error in opening the filename – %s “,filename );


fputs(newvalue,pfile );

fputs( “\n”,pfile );

fclose( pfile );

LoadRunner:   Anatomy of a Script

When you record and save a LoadRunner script in Vugen, there are a number of files that are created. Here’s what they are, and what they do and identification of the files you can safely delete..

Files Required for Playback
During the course of recording and playback of scripts, the Vugen application will create many files, but only some of them are necessary for playback (either in Vugen or the Controller).

For example, say you have script named PerformancEngineer, with two Actions, Home and Forums, then the required files you would need in the PerformanceEngineer script directory would be:

* PerformanceEngineer.usr
* default.usp
* default.cfg
* globals.h
* Home.c
* Forums.c
* vuser_init.c
* vuser_end.c
* PerformanceEngineer.prm

Here’s what is in each file:

PerformanceEngineer.usr: Primarily, the .usr file defines which actions are used by the script. There are other properties which define which protocols are used and other settings, but most of the info

default.usp: Contains the run logic for the script

default.cfg: Contains the run-time settings (except for run-logic)

globals.h: The global headers file- visible and editable in Vugen

*.c (Action files): These are the action files containing your script code. You can edit these files in any text editor, if you want. Sometimes it is easier than starting up Vugen

PerformanceEngineer.prm: Containes the parameter definitions

*.dat: Your data files, you can save these in the script directory or somewhere else, even a mapped network drive on a different server
Files Created During Vugen Playback

All of the files listed below can safely be deleted and not affect your ability to use the script.

result1: One or more result directories are created which contain script playback results

*.idx: The .idx files are binary “index” files created by Vugen for holding parameter values

combined_PerformanceEngineer.c: A list of #includes for all of your Actions

logfile.log, mdrv.log: random log files which you will probably never need to look at

mdrv_cmd.txt, options.txt: These text files contain commands and arguments for the script compiler and driver (mdrv) and are created dynamically, so you can safely delete them.

output.txt: This one is important. This file contains all of the log messages generated during script playback. The contents of this file appear in the “Output Window” section of Vugen

output.bak: A backup of the above file

pre_cci.c: Output from the C pre-processor, which contains all of the functions used in your scrip, from all of the Acitons and header files.

In summary, you can delete: *.txt, *.log, *.idx, *.bak, result*, pre_cci.c, combined_*, *.ci
Files Created During Recording

The ‘data’ directory in your script directory contains the script recording data. I usually delete this so it doesn’t get checked into my version control system, but you may want to keep it around if you use the graphical scripting mode and/or you want to compare playback vs. recording. The auto-correlation feature makes use of this data, too, but I haven’t had much sucess using that feature.

(This has been referred from the site

Working with a firewall means that you can prevent unauthorized access to or from a private network, on specific port numbers.

In a regular LoadRunner load test scenario (not over a firewall), the Controller has direct access to the LoadRunner agents running on remote machines. This enables the Controller to connect directly to those machines. When running Vusers or monitoring applications over a firewall, this direct connection is blocked by the firewall. The connection cannot be established by the Controller, because it does not have permissions to open the firewall.

LoadRunner solves this problem by using a communication configuration based on HTTPS or secured TCP/IP. This configuration uses the standard SSL port on the firewall (port 443).

A LoadRunner agent is installed on load generators running Vusers over a firewall, and on Monitor Over Firewall machines that monitor the servers that are located over a firewall. The agent communicates with the MI Listener machine through port 443 in the firewall. The MI Listener is a component that serves as router between the Controller and the LoadRunner agent.

When the LoadRunner agent connects to the MI Listener, the MI Listener keeps a listing of the connection to the agent using a symbolic name that the agent passed to it. When the Controller connects to the MI Listener, it communicates to the MI Listener through port 50500.

Setting Up your System to Use Firewalls:

Basic Steps Setting up your system to use firewalls involves the following stages of configuration: Installation and initial configuration Running Vusers over a firewall Installation and initial configuration

To enable over-firewall communication, ensure that you have installed the following LoadRunner components:

MI Listener Monitor Over Firewall component To perform initial configuration of your over-firewall system:

1 Configure your system according to TCP or HTTPS.

2 Modify your firewall settings to enable communication between the machines on either side of the firewall.

3 Configure the MI Listener.

Configuring the MI Listener To configure the MI Listener:

1 Open incoming HTTPS service for port 443. The port settings are set by your system administrator.

2 Stop the LoadRunner agent on the MI Listener machine by right-clicking its icon in the system tray and selecting Close from the popup menu.

3 Run MI Listener Configuration from Start > Programs > LoadRunner > Advanced Settings, or run \launch_service\bin\MILsnConfig.exe.

4 Set each option as described in the following table:

5 Click OK to save your changes, Cancel to cancel them, or Use Defaults.

6 Restart the LoadRunner agent by double-clicking the shortcut on the desktop, or choosing Start > Programs > LoadRunner.

7 Make sure that port 443 is free on the MI Listener machine.

Running Vusers over a firewall

To set up your system to run Vusers over a firewall:

1 On each load generator machine that will be running over a firewall, configure the LoadRunner agent to communicate with the MI Listener.

2 Configure the Controller machine to recognize the load generator and MI Listener machines.

Configuring LoadRunner Agents Over the Firewall

1 Stop the LoadRunner agent by right-clicking its icon in the system tray and selecting Close.

2 Run Agent Configuration from Start > Programs > LoadRunner > Advanced Settings, or run \launch_service\bin\AgentConfig.exe.

3 Select the Enable Firewall Agent check box, and then click Settings. The Agent Configuration dialog box opens.

4 Set each option as described in “Agent Configuration Settings”

5 Click OK to save your changes, or Cancel to cancel them.

6 Restart the LoadRunner agent by double-clicking the shortcut on the desktop, or select Start > Programs > LoadRunner > LoadRunner Agent Service/Process.

7 Check the connection status between the LoadRunner agent and the MI Listener.

Configuring the Controller for Running over a Firewall

1 Run the Controller from Start > Programs > LoadRunner > Applications > Controller and create a new scenario, or load an existing one.

2 Click Generators to display the Load Generators window. In the Name field, enter the symbolic name of the server. This is the same name that you entered in the Local Machine Key setting in the Agent Configuration.

3 Select the Load Generator, and click Details to display the Load Generator Information.

4 In the Security tab, enter the MI Listener machine’s name in the MI Listener field. This is the same name that you entered in the MI Listener Name setting of the Agent Configuration dialog box. In this example, the MI Listener is bunji.

5 In the Firewall Settings section, select one of the following options: ➤ Enable running Vusers over Firewall. To run Vusers over the firewall. ➤ Enable Monitoring over Firewall. To monitor Vusers over the firewall.

6 Click OK to return to the Load Generators dialog box.

7 Select the load generator and click Connect. This will do all the setup required to run your test over the firewall…

All files located in %temp% and %tmp% folders of the Controller, VuGen, and LoadGenerator machines can be safely removed after a script has been saved, the scenario run, and the results collated, analyzed, and saved.


The following are temporary files created by LoadRunner:


The Brr_xxxx folder contains raw data collected by the Controller during runtime. These data will be collated and copied to the result folder after the scenario completes and are safe to delete if collation completes.


The folder contains runtime information of the load test and is safe to delete.


The folder is another runtime information folder; it contains information about monitors and is safe to delete.


Res is the default result folder, you should move it to a different location for safe keeping. You can also specify the result folder by selecting Result -> Result Settings in the Controller.


Aes_log.txt, drv_log.txt, ResmonLog.txt, ResmonLogBrief.txt, and are all log files and are needed only for debugging purposes in case of a problem.


Noname*, vuac*, vxml*, and unq* are all script-related files and can be removed once the script has been saved.


JET1858.tmp is an MS Jet temp file used during the collation process. It is safe to delete once collation finishes.

There is a simple way to examine, whether the load test which we conducted is to a real extent or not.


The factors which we have to capture is


Hits per second,

Avg Response time,

Think Time

No of users simulated.


Thus substituting all the gathered data in the formula,


Total Number of users executed = (Response Time + Think Time) * Request per second



Thus while calulating using the formula, the result value should equal or should be greater than the total number of users executed.


From this deal we can able to find out, how much users the servers can handle. If the result value goes below the total numbers executed, then the servers are not capable to server these many users.


The Page size also can be verified using,


Page size = Throughput / Hits per second.