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: Web Application Server
Hits per Second ,HTTP Responses per Performance Monitors:
Second ,Pages Downloaded per Allaire ColdFusion ,Ariba , ATG
Second ,Throughput , Transaction Dynamo
Response Time ,Transaction per BEA WebLogic (via JMX) , BEA
Second (Passed) ,, User-defined Data WebLogic (via SNMP) ,BroadVision
Point , Virtual User Status ,Web IBM WebSphere ,iPlanet Application
Transaction breakdown Graphs Server ,Microsoft COM+ Monitor
Microsoft Active Server Pages ,Oracle
Server Monitors: 9iAS HTTP Server , SilverStream .
NT server resources ,UNIX / Linux
server monitor Firewall Server Resource Monitors:
CheckPoint FireWall .
Network Monitors:
Network delay monitor , SNMP monitor Database Server Resource
Monitors:
Web Server Performance Monitors: SQL Server , Oracle , DB2 , Sybase .
Apache ,Microsoft IIS ,iPlanet
Java Performance Monitors :
ERP Performance Monitors : TowerJ , JProbe ,J2EE Performance
SAP R/3 Monitor 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
[Link]
[Link]
Load Requests from
Requests from balancing [Link]
[Link] system go to Database
[Link] go to Database Server 2
Server 1
Requests from
[Link]
go to Database
Server 3
IP Address usage by Load Balancing Systems
Databases
Application
servers
Web
Virtual Routers serve
users r
[Link]
[Link]
[Link]
[Link] 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
[Link]
[Link]
[Link]
[Link]
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
[Link] – Contain info about the virtual user type, AUT, Auction
files etc.
[Link] – A copy of the [Link] before the last save operation.
[Link] – Contains the run-time settings as defined in Vugen
application.
[Link] – The original recorded API calls.
[Link] – Contains column headers for grids in the database
scripts.
Files Generated During Recording (Contd…)
[Link] – 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:
[Link] – 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 [Link] is invoked to fill in any
macro or preprocessor directives etc.
pre_cci.c – is created which is a C file(defined in
[Link] file).
[Link] – 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…)
[Link] 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. [Link] takes pre_cci.c as input file.
Pre_cci.ci - is created which is renamed as [Link].
Thelog file is checked for log messages, then check whether
[Link] has been built.
The driver is run takng [Link] and .user file as input. The .usr file
tells the driver which database to be used.
[Link] 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++ [Link] 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: [Link] and [Link]
[Link] : This file resides in the M_LROOT\dat directory and contains general
information about VuGen to be used by both VuGen and Controller. [Link] 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 [Link] file contains settings that indicate the OS and
other compilation related files.
[Link] : 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 [Link] file:
Add a new section with the new protocol’s settings. We can add a new driver by editing the
[Link] 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 [Link] file, or place one file called
[Link] 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 [Link], and globals.h
files in this subdirectory.
References
LoadRunner Reference Manual
[Link]
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@[Link]