Advanced LoadRunner

IVS-TRAINING
Ground Rules

 Please mute your mobile phones

 Stick to timeliness

 Help each other in learning – as learning is a continuous process

 Please participate actively to make the session interactive.

Session Objectives

To familiarize with some of the advanced features of LoadRunner

like
 Parameterization

 Correlation

 Monitoring Servers over a Firewall

 Performance Monitoring
 Load Balancing and IP Spoofing
At the End of Session you would be able to:

 Record a script and parameterize it with different types

 Appreciate the concept of correlation and the different types

 Know the way to Monitor your servers over firewalls

 Appreciate the concept of Spoofing IP addresses for Load

Balancing
Parameterization
Parameterization

When you record a Business Transaction, VuGen generates a

script composed of functions. The values of the arguments in the
functions are the actual values used during the recording session
– Hard Coded.

Need for Parameterization

 Do not want to repeatedly use same values
 It provides the ability to test your script with different values
 Reduces the size of script
Steps required for Parameterization
 Replacing the constant values in the Vuser script with
parameters
 Setting the properties and data source for the parameters

Limitations
 You can use parameterization only for the arguments
within a function.
Parameter Types

Internal Data : Data that is generated internally by the Vuser.

Ex. Date/Time, iteration number, VuserID, Unique number.

Data Files :Data that is contained in a file or database.

Ex. Flat files, .DAT files or using the Data Wizard to import
from the database.
User-Defined Functions : It replaces the parameter with a
value returned from a function located in an external DLL
(Dynamic link library).
Parameter Types

Format of the parameter

 Theformat specifies the length and structure of the resulting
parameter string.
 The resulting parameter string is the actual parameter value together
with any text that accompanies the parameter.  
 Theuser can create a format using a combination of text or number
formats.  
 When using the Date/Time, Random, Unique, and User-Defined
Function parameter types, VuGen lets the user specify the update
method for the parameters. To set the update method, select a
method from the Update value on list - Each Occurrence, Each
Iteration, Once
Correlation
Correlation
Correlation is the process to parameterize the dynamic data returned from the server.

The process of correlation is carried out basically :

To simplify or optimize the code
For dynamic data from the server
To accommodate unique data records
Steps
Compare the scripts and determine the values to correlate
Creating a variable
Reference the saved values
Setting Correlation Rules
The user can add, modify, or remove rules from the Correlation
tab.
The user can also edit rules that were created automatically for
application server environments.
Modes of Correlation

Statements can be correlated either during recording or after recording.

 During Recording
 Built-In Correlation
 User-Defined Rule Correlation
 After Recording - VuGen's snapshot comparison method
 Used if the user is recording a session on an unsupported application server
whose context is not known, and the user cannot determine any correlation
rules.
Before Recording – Built in Correlation
The Built-In correlation detects and correlates dynamic data for supported
application servers. Most servers have clear syntax rules, or contexts, that they
use when creating links and referrals.

For example, BroadVision servers create session IDs that are always placed
between the same delimiters: ”BV_SessionID=” on the left, and ”&” on the
right.

BV_SessionID=@@@@1303778278.0969956817@@@@&

If you are recording a session with a supported application server, you can use
one of the existing rules built-in to VuGen. An application server may have more
than one rule. You can enable or disable a specific rule by selecting or clearing
the check box adjacent to the rule. VuGen displays the rule definitions in the right
pane.
Before Recording - User Defined Rule Correlation

 Ifyour application has unique rules, and you

are able to determine them clearly, you can
define new rules using the Recording Options.
 User-defined rule correlation requires you to
define correlation rules before you record a
session. You create the correlation rules in the
Recording Options dialog box. The rules
include information such as the boundaries of
the dynamic data you want to correlate and
other specifications about the match such as
binary, case matching, and the instance
number.
Before Recording - User Defined Rule Correlation
 You instruct VuGen where to search for the criteria:
 All Body Text - The Search for Parameters in all of the Body Text option
instructs the recorder to search the entire body for a match. It searches for
text, using the borders that you specify.
 Link/Form Actions - The Search for parameters in links and form actions
method instructs VuGen to search within links and form type actions for the
text to parameterize. This method is for application servers where you
know the context rules. You define a left boundary, a right boundary, an
alternate right boundary, and an instance (occurrence) of the left boundary
within the current link.
 Form Field Value - The Parameterize form field value method instructs the
recorder to save the named form field to a parameter. It creates a
parameter and places it in the script before the form’s action step – For
applications with many forms.
 Cookie Headers - The Search for Parameters from Cookie Header method
is similar to the previous rule, except that the value is extracted from cookie
text (exactly as it appears in the recording log) instead of from a link or form
action.
After Recording – Snap Shot Comparison Method

 If you disabled automatic correlation, or if the automatic method

did not detect all of the differences, you can use VuGen’s built-in
correlation mechanism, to find differences and correlate the
values. You can also use this mechanism for scripts that were
only partially correlated.

 The correlation mechanism uses snapshots to track the results

of script execution. Snapshots are graphical representations of
Web pages.

 VuGen creates a base snapshot during recording, and generates

a new snapshot every time you execute the script.
After Recording – Snap Shot Comparison Method (contd..)
 Compare the recorded snapshot to any one of the replay
snapshots to determine which values you need to correlate in
order to insure a successful execution of the script.
 The Web correlation mechanism has a built-in comparison
(wdiff) utility that allows you to view the text or binary differences
between the snapshots. You can then correlate the differences
one-by-one or all at once.
 Use web_reg_save_param to correlate the dynamic values.
Monitoring Servers over a Firewall
Monitoring Servers over Firewall
The machines inside the firewall can either be Load Generator machines running Vusers, or
mediator machines connected to the servers to be monitored by the Controller. You configure
the LoadRunner agents inside the firewall to operate over the firewall. The Controller machine
resides outside the firewall.

Inside Network Outside Network

Monitoring … Steps

 Configure the LoadRunner agent and configure it for it to

connect it a MI Listener (outside the firewall) .

 Configure the firewall –

Modify your firewall settings to enable communication between the machines
inside the firewall and machines outside the firewall.
 TCP Configuration - The LoadRunner agent tries to establish a connection with the MI
Listener using port 443. To enable this connection, allow an outgoing connection for the
HTTPS service on the firewall for port 443. This causes the agent to keep trying to connect
to the MI Listener at intervals specified (in seconds) in the Connection Timeout field of the
agent configuration. The MI Listener then connects back to the agent. From this point on,
the agent listens to commands from the MI Listener.

 HTTPS Configuration - The LoadRunner agent tries to establish a connection with the
MI Listener using the proxy port specified in the Proxy Port field. To enable this
connection, allow an outgoing connection for the HTTPS service on the firewall for port
443. This causes the agent to keep trying to connect to the MI Listener at intervals
specified (in seconds) in the Connection Timeout field of the agent configuration. On
successful connection, the agent on the proxy server connects to the MI Listener, and the
MI Listener connects back to the agent through the proxy server. From this point on, the
agent listens to commands from the MI Listener.
Monitoring … Steps (contd…)

 Install the Monitoring over Firewall Component in a machine in

the firewall.

 Install the MI Listener on a machine outside the firewall.

 Configure the security attributes on each MI Listener machine.

 Configure the Controller machine to recognize the agent and MI

Listener machines.
TCP Configuration

The TCP configuration requires every Load Runner agent machine behind the
Firewall has to be allowed to open a port in the firewall for outgoing
communication. If this is the firewall configuration at hand, use the TCP
configuration.
HTTPS Configuration
In the HTTPS configuration, only one machine (the proxy server) is allowed to
open a port in the firewall. Therefore it is necessary to tunnel all outgoing
communications through the proxy server
MI Listener Installation and Configuration
To enable running Vusers or monitoring over a firewall, you need to install the MI
Listener on one or more machines outside the firewall in the same LAN as the
Controller and configure it.

Notes:

MI Listener can only be installed on Windows machines.

Controller installation automatically includes the MI Listener,
so you can designate the Controller as the MI Listener
machine.
Ensure that no Web Servers are running on the MI Listener or
Monitor over Firewall machine. These servers use port 443
and will not allow the access required by the listening and
monitoring processes.
Configuring the Controller to Run or Monitor Vusers over
a Firewall

To run Vusers or monitor servers inside the firewall, you need to create a unique
connection between the Controller and the agent machine. This connection is
made through the Mercury Interactive listener machine ("MI Listener"), which
serves as a router between the Controller and the LoadRunner agent. To
establish this connection, you configure the Controller machine to define the
agent machine as a load generator.

Refer: LoadRunner Help manual

Performance Monitoring
Performance Monitoring

 To minimize the impact of the monitoring on the system under

test, LoadRunner is capable of extracting data without having to
install intrusive capture agents on the monitored servers.

 As a result, LoadRunner can be used to monitor the

performance of the servers regardless of the hardware and
operating system on which they run.

 Setup and installation of the monitors therefore is trivial. Since all

the monitoring information is sampled at a low frequency
(typically 1 to 5 seconds) there is only a negligible effect on the
servers.
Monitors Supported
Client-side Monitors:
Hits per Second ,HTTP Responses per
Second ,Pages Downloaded per
Second ,Throughput , Transaction
Response Time ,Transaction per
Second (Passed) ,, User-defined Data
Point , Virtual User Status ,Web
Transaction breakdown Graphs
Server Monitors:
NT server resources ,UNIX / Linux
server monitor
Network Monitors:
Network delay monitor , SNMP monitor
Web Server Performance Monitors:
Apache ,Microsoft IIS ,iPlanet
ERP Performance Monitors :
SAP R/3 Monitor
Web Application Server
Performance Monitors:
Allaire ColdFusion ,Ariba , ATG
Dynamo
BEA WebLogic (via JMX) , BEA
WebLogic (via SNMP) ,BroadVision
IBM WebSphere ,iPlanet Application
Server ,Microsoft COM+ Monitor
Microsoft Active Server Pages ,Oracle
9iAS HTTP Server , SilverStream .
Firewall Server Resource Monitors:
CheckPoint FireWall .
Database Server Resource
Monitors:
SQL Server , Oracle , DB2 , Sybase .
Java Performance Monitors :
TowerJ , JProbe ,J2EE Performance
Monitor
Coffee Break !!
Load Balancing Systems
&
IP Spoofing
IP Address usage by Load Balancing Systems
 Routing of web client request is IP related.
 A load balancing system may distribute requests to application
servers and backend databases according to the client IP address
that sent the request.
 Virtual users generally reside on single IP address. Virtual users at
one IP address create unrealistic load on routers, application servers,
and backend databases.
 Unbalanced Load Modeling Causes Uncertain Test Results.
 Virtual users from many "spoofed" IP addresses create realistic load
on entire multi-tiered system So the IP spoofing is used on load
generators.
 Load Balancing Systems

Databases

Application
servers
Virtual users with Web
IP Spoofer Routers serve
r
103.14.255.200

200.37.66.9
Load Requests from
Requests from balancing 103.14.255.200
200.37.66.9 system go to Database
144.100.105.88 go to Database Server 2
Server 1

Requests from
144.100.105.88
go to Database
Server 3
IP Address usage by Load Balancing Systems

Databases

Application
servers
Web
Virtual Routers serve
users r

200.37.66.9
200.37.66.9
200.37.66.9
200.37.66.9 Load
balancing
system

Virtual
Virtualusers
usersatatone
oneIP
IPaddress
addresscreate
create
unrealistic
unrealistic load on routers, applicationservers,
load on routers, application servers,
and backend databases
and backend databases
IP Spoofing

Databases

Application
servers
Virtual users with Web
IP Spoofer Routers serve
r

200.37.66.9
144.100.105.88
191.230.1.0
103.14.255.200
Load
balancing
system

Virtual
Virtualusers
usersfrom
frommany
many"spoofed"
"spoofed"IP IPaddresses
addresses
create
create realistic load on entire multi-tieredsystem
realistic load on entire multi-tiered system
How to Implement IP Spoofing
 Run the IP Wizard on each Vuser host machine

 Enable the IP Spoofer from the Controller's main menu

 Disable modem emulation in the Run-Time Settings

 Invoke IP Wizard from the LoadRunner program group

 IP Wizard Step 1 - Select "New Settings"
 IPWizard Step 2 - Enter IP address of Web server, This step is necessary for automatic updating of the Web
server's routing table. Routing tables identify a packet's next step by looking up the destination IP address.

 Start
How To Implement IP Spoofing
 IP Wizard Step 3 - Add IP addresses that will load balance your system.

 Start
How To Implement IP Spoofing
 Add Intranet/LAN Addresses Class C Example
199 . 199 . 199 . 0
netid hostid
3 bytes define the network;
1 byte defines up to 256 client nodes.

Class B Example
199 . 199 . 0 . 0
netid hostid
2 bytes define network;
Enter a range of IP 2 bytes define client nodes.
addresses representing TIP
nodes on a LAN
Your network Class A Example
administrator
199 . 0 . 0 . 0
can provide
199 . 199 . 1 . 0 netid hostid
valid IP
199 . 199 . 1 . 1 addresses for 1 byte defines the network;
your network 3 bytes define client nodes.
199 . 199 . 1 . 2
199 . 199 . 1 . 3
How To Implement IP Spoofing
 IP Wizard Step 4 - IP Wizard Summary - Check Reboot now to update routing tables.
This ensures that the Web server remembers paths to virtual clients .

 Start
How To Implement IP Spoofing

 IP Wizard Step 5 - Select Enable IP

Spoofer from the Controller's Scenario
menu.

 Make sure that Emulate modem speed is

DISABLED in Run-Time Settings, or IP
Spoofing will not work.
 Integration with
other MI Products
Integration of Load Runner with WinRunner
Why Load Runner and WinRunner integration?

 Generally MI recommends to use WinRunner when the Application

to be tested is such that Load Runner cannot record it .This could
happen when the application is using a proprietary protocol the
VuGen cannot record against or the Application is using multiple
protocols .The solution to this involves using WinRunner , a
Functional testing tool , to operate the GUI portions of the application
to be tested.
 A WinRunner script has the limitation of running only one Vuser per
machine; this however can be overcome by integrating Load Runner
with WinRunner. This enables the User to run more than one GUI
Vuser per machine. The execution of GUI scripts on the individual
sessions are controlled by Load Runner. Load Runner will interact
with each session within which a GUI Vuser will be run using
WinRunner .The WinRunner replay will more accurately stress the
server because WinRunner runs against the GUI of the application
and Load Runner does not.
Launch WinRunner from Load Runner

 Save a copy of the WinRunner script to the Load Runner controller

machine. If the user plans to run the script on a remote machine , the
user still needs to save a copy of the script in the controller machine
 Bring up the Load Runner controller .User can select either manual or
Goal oriented scenario.
 Click on “Browse” in the new scenario window
 An “Open Test” window will pop-up .Change the “File of type” to GUI
scripts
Launch WinRunner from Load Runner (Contd…)
 Note that when the user navigates to a directory that has the WinRunner
script , the corresponding WinRunner script icon will show
 After adding this, the WinRunner script will be added to Load Runner
controller
 Before running the script, click on ”Generators”, select the relevant host,
and click on “Details” . Make sure that “GUI/ WinRunner” is selected
under the Vuser limit tab
 Now the WinRunner script can be run from Load Runner controller
Note : For running the script on remote machine the user needs to take care of the
following:
 The WinRunner script runs fine on that machine using WinRunner
 Load Runner agent process is started on the remote machine
Integration of Load Runner with Test Director
Need for integration
 Load Runner works together with Test Director, Mercury Interactive's
Web-based test management tool. Test Director provides an efficient
method for storing and retrieving Vuser scripts, scenarios, and collecting
results. The user store scripts in a Test Director project and organize
them into unique groups.

Connection Process
The connection process has two stages.

 First, the users connect Load Runner to a local or remote Test Director
Web server. This server handles the connections between Load Runner
and the Test Director project.
 Next, the user choose the project the user want Load Runner to access.
The project stores the scripts for the application the user are testing.
Note that Test Director projects are password protected, so the user
must provide a user name and a password.
Integration of Load Runner with Test Director
Steps:

 In the Controller, choose Tools > Test Director Connection. The

Test Director Connection dialog box opens.
 In the Server box, type the URL address of the Web server on
which Test Director is installed
Opening Scripts from a Test Director Project
When Load Runner is connected to a Test Director project, the user can open the scripts from
Test Director. The user locates tests according to their position in the test plan tree, rather than
by their actual location in the file system.

Steps:

 Connect to the Test Director server

 In VuGen, choose File > Open or click the File Open button. The Open Test
from Test Director Project dialog box opens and displays the test plan tree.
 To open a script directly from the file system, click the File System button.
The Open Test dialog box opens. (From the Open Test dialog box, the user
may return to the Open Test from Test Director Project dialog box by
clicking the Test Director button.)
 Note that when the user select a subject, the scripts that belong to the
subject appear in the Test Name list.
 Select a script from the Test Name list. The script appears in read-only.
Click OK to open the script. VuGen loads the script.
Miscellaneous
Files Generated During Recording

When we record and save the script, a number of important files are generated along
with the main file:, If we save the file as vuser

 vuser.usr – Contain info about the virtual user type, AUT, Auction
files etc.
 vuser.bak – A copy of the vuser.usr before the last save operation.
 default.cfg – Contains the run-time settings as defined in Vugen
application.
 vuser.asc – The original recorded API calls.
 vuser.grds – Contains column headers for grids in the database
scripts.
Files Generated During Recording (Contd…)
 default.usp – Contains script’s run-logic, including how the
actions sections run.
 init.c – Exact copy of the Vuser_init function as seen in the
Vugen window.
 run.c – Exact copy of Action function as seen in the Vugen
window.
 end.c - Exact copy of the Vuser_end function as seen in the
Vugen window.
 vdf.h – A header file of C variable definitions used in the script.
 \Data – The Data directory stores all the recorded data used
primarily as backup. Once the data is in this directory, it is not
touched or used.
Files Generated During Replay
When the script is played back, following files are generated:

options.txt – this file includes command line parameters

to the preprocessor.
vuser.c – It contains includes to all the relevant .c
and .h files.
The c preprocessor cpp.exe is invoked to fill in any
macro or preprocessor directives etc.
pre_cci.c – is created which is a C file(defined in
options.txt file).
logfile.log – is created containing any output of this
process. This file should be empty as a proof of
successful completion of the process.
Files Generated During Replay (Contd…)
 Cci.exe C pre compiler is invoked to create a platform dependent
pseudo binary file(.ci) to be used by driver program to interpret it
at runtime. cci.exe takes pre_cci.c as input file.

 Pre_cci.ci - is created which is renamed as vuser.ci.

 Thelog file is checked for log messages, then check whether

vuser.ci has been built.

 The driver is run takng vuser.ci and .user file as input. The .usr file
tells the driver which database to be used.

 output.txt file is created which contain all the output messages.

Code generation language
The mode of code generation can be either C Language or Visual Basic Scripting
Steps:

 Choose Tools > Recording Options from the main menu or click
Options... in the Start Recording dialog box. The Recording Options
dialog box opens. Click the Script tab.

 Inthe Select Script Language box, select a mode of code generation

— C Language or Visual Basic Scripting.
Note: Use C for recording applications that use complex
constructs and C++ code.Use Visual Basic Scripting mode to
record script-based applications.

 Start
Code generation language
The scripts can be written in Java also. Various java API’s are provided by LR which
can be used for generating the scripts.

Steps to convert a web script to a java script:

Create an empty Java Vuser script and save it.
Create an empty Web Vuser script and save it.
Record a web session using standard HTML/HTTP recording.
Replay the Web Vuser script. When it replays correctly, cut and
paste the
entire script into a text document and save it as a text .txt file. In the
text file
modify any parameter braces from the Web type,"{}" to the Java
type, "< >".

 Start
Code generation language
Open a DOS command window and go to the
<LOADRUNNER>/dat
directory.
Typethe following command:<LOADRUNNER>/bin/sed -f
web_to_java.sed filename > outputfilename
where filename is the full path and file name of the text file the
user saved earlier and outputfilename is the full path and
filename of the output file.
Iteration blocks
Iteration blocks are groups of actions within the Vuser script.
The user configure each block independently—its sequence, weighting, and
iterations.
Steps :
 In the Pacing tab, right-click the word Run in the tree view and
choose Insert Actions Block. VuGen inserts a new Action block
with the next available index
 Right-click the word Block and choose Insert Into Block >
Actions. The Select Actions list opens.
 Select an action to add to the block
and click OK.
Note: User can only add actions that exist and
are displayed in the Actions section in VuGen's left pane.
 Start
 Iteration blocks (Contd …)
Setting an Action Sequence
Action blocks or individual actions can be executed either sequentially or randomly.

 In the default sequential mode, the Vuser executes the blocks or

actions in the order they appear in the iteration tree view.
 To change the sequential order of blocks or actions:
 In the Pacing tree view, select the item the user want to move and perform a
right-click. A menu opens.

 Choose Move Item Up or Move Item Down to modify the item's position.

 The user can also run blocks or actions randomly.

 When the user set actions to run randomly, VuGen assigns an even
weighting to all the items—all items are given equal execution time.
 Iteration blocks (Contd …)
Setting Action Weightage
When the user run actions randomly, the user can indicate the rate at which Load
Runner executes each action. By default, Load Runner assigns an equal weighting to
all the actions.
Steps to set the weighting of blocks or action :

 Right click the item whose percentage needs to be changed, and

choose Properties.
Iteration blocks
The Action Properties dialog opens.

Specify the desired percent for the selected

block or action.
Click OK.
Repeat the above steps to adjust the other
actions so that the total percentages equal 100.
Note : Make sure that the run logic for the item the user wants
to set is Random. If a percentage appears next to the item, it is
in random mode.
Examining the .dat files
There are two .dat files used by VuGen: vugen.dat and mdrv.dat
 vugen.dat : This file resides in the M_LROOT\dat directory and contains general
information about VuGen to be used by both VuGen and Controller. VuGen.dat file has the
following sections:
 [Templates] RelativeDirectory = template, This indicates where the
templates are for the particular VuGen protocols. Default entry indicates that they are
in a relative template directory. Each protocol has a separate sub-directory under
template, which contains the template files for the protocol.
 [GlobalFiles] This section contains a list of files(main.c, .usr, .cfg,
.usp etc.) that VuGen copies to test directory when we create a new test.
 [ActionFiles] It contains the name of the file containing the actions
to be performed by the Vuser and upon which to perform the iterations.

In addition to these sections the vugen.dat file contains settings that indicate the OS and
other compilation related files.

 mdrv.dat : This file contains separate section for each protocol defining the location of the
library files and driver executables. This file is modified, when we want to add a new Vuser
type/ Protocol.
Adding a new Vuser type / Protocol
To add a new Vuser type/Protocol, we need to :

 Edit the mdrv.dat file:

Add a new section with the new protocol’s settings. We can add a new driver by editing the
mdrv.dat file itself. Else the vuser will use default driver.

 Add a new .cfg file:

We can specify a cfg file to set the default runtime settings and recording options for the
protocol. We define it in the LibCfgFunc variable in the mdrv.dat file, or place one file called
default.cfg in the new protocols subdirectory under templates.

 Insert an .lrp file:

In the dat/protocols directory, insert as lrp file which defines the protocol. This file contains the
configuration information for the protocol in the protocol, Template, Vugen, and API sections.

 Create a Template directory: Insert a subdirectory to M_LROOT/template with a name

corresponding to the protocol name defined in the .lrp file. Insert default.cfg, and globals.h
files in this subdirectory.
References

 LoadRunner Reference Manual

 www.mercury.com
Questions?
 Thank You!!

IVS-TRAINING

Please note that submission of Course and Instructor feedback is

mandatory for availing attendance for the Course.

Any doubts or suggestions for improvement can be forwarded to:

IVS_TRAINING@infosys.com