Load Runner

Understanding the LoadRunner

To load your client/server system, LoadRunner emulates an
environment where
Multiple users work concurrently. While the client/server system is under
load, LoadRunner accurately measures and analyzes the system
performance, and its functionality.
Client/Server Load Testing
Modern client/server architectures are complex. While they provide an
unprecedented degree of power and flexibility, these systems are difficult to
test. Whereas single-user testing focuses primarily on functionality and the
user interface of a single application, client/server testing focuses on
performance and reliability of an entire client/server system.
For example, a typical client/server testing scenario might depict 200
users that login simultaneously to a system on Monday morning: What is the
response time of the system? Does the system crash? To be able to answer
these questionsand morea complete client/server performance testing
solution must:
Test a system that combines a variety of software applications and
hardware platforms
Determine the suitability of a server for any given application
Test the server before the necessary client software has been
developed
Emulate an environment where multiple clients interact with a single
server application
Test a client/server system under the load of tens, hundreds, or even
thousands of potential users
Manual Testing Limitations
Traditional or manual testing methods offer only a partial solution to
load testing. For example, you can test an entire system manually by
constructing an environment where many users work simultaneously on the
system. Each user works at a single machine and submits input to the
system. However, this manual testing method has the following drawbacks:
It is expensive, requiring large amounts of both personnel and
machinery
Testing Tools LoadRunner

#1#

 It is complicated, especially coordinating and synchronizing multiple

testers
It involves a high degree of organization, especially to record and
analyze results meaningfully
The repeatability of the manual tests is limited
The LoadRunner Solution
The LoadRunner automated solution addresses the drawbacks of
manual performance testing:
LoadRunner reduces the personnel requirements by replacing human
users with virtual users or Vusers. These Vusers emulate the behavior
of real usersoperating real applications.
Because numerous Vusers can run on a single computer, LoadRunner
also reduces the hardware requirements.
The LoadRunner Controller allows you to easily and effectively control
all the Vusersfrom a single point of control.
LoadRunner automatically records the performance of the client/server
system during a test. You can choose from a wide variety of graphs and
reports how you want to view the performance data.
LoadRunner checks where performance delays occur: network or client
delays, CPU performance, I/O delays, database locking, or other issues
at the database server.
LoadRunner monitors the network and server resources to help you
improve performance.
Because LoadRunner tests are fully automated, you can easily repeat
them as many times as you need.
Understanding LoadRunner Introduction Using LoadRunner
Using LoadRunner, you divide your client/server performance testing
requirements into scenarios. A scenario defines the events that occur during
each testing session. Thus, for example, a scenario defines and controls the
number of users to emulate, the actions that they perform, and the machines
on which they run their emulations.
In the scenario, LoadRunner replaces human users with virtual users or
Vusers. When you run a scenario, Vusers emulate the actions of human users
submitting input to the server. While a workstation accommodates only a
single human user, many Vusers can run concurrently on a single
workstation. In fact, a scenario can contain tens, hundreds, or even
thousands of Vusers.
To emulate conditions of heavy user load, you create a large number of
Vusers that perform a series of tasks. For example, you can observe how a
Testing Tools LoadRunner

#2#

server behaves when one hundred Vusers simultaneously withdraw cash

from the bank ATMs. To accomplish this, you create 100 Vusers, and each
Vuser:

Enters an account number into an ATM

Enters the amount of cash to withdraw
Withdraws cash from the account
Checks the balance of the account
Repeats the process numerous times

The actions that a Vuser performs during the scenario are described in a
Vuser script. When you run a scenario, each Vuser executes a Vuser script.
The Vuser scripts include functions that measure and record the performance
of the server during the scenario. To measure the performance of the server,
you define transactions.
Transactions measure the time that it takes for the server to respond to
tasks submitted by Vusers. For instance, you can define a transaction that
measures the time it takes for the server to process a request to view the
balance of an account and for the information to be displayed at the ATM.
You insert rendezvous points into Vuser scripts to emulate heavy user load on
the server.
Rendezvous points instruct multiple Vusers to perform tasks at exactly
the same time. For example, to emulate peak load on the bank server, you
insert a rendezvous point to instruct 100 Vusers to simultaneously deposit
cash into their accounts. You use the LoadRunner Controller to manage and
maintain your scenarios.
Using the Controller, you control all the Vusers in a scenario from a
single workstation. When you execute a scenario, the LoadRunner Controller
distributes each Vuser in the scenario to a host. The host is the machine that
executes the Vuser script, enabling the Vuser to emulate the actions of a
human user. Vuser scripts include functions that measure and record system
performance during load-testing sessions. During a scenario run, you can
monitor the network and server resources. Following a scenario run, you can
view performance analysis data in reports and graphs.
The LoadRunner Testing Process
You can easily create and run load-testing scenarios by following the
LoadRunner testing process below. The following illustration outlines the
testing process:

Testing Tools LoadRunner

#3#

Step I: Planning the Test

Successful load testing requires that you develop a thorough test plan.
A clearly defined test plan will ensure that the LoadRunner scenarios that
you develop will accomplish your load testing objectives.
Step II: Creating the Vuser scripts
Vusers emulate human users interacting with your client/server
system. A Vuser
script contains the actions that each virtual user performs during scenario
execution.
In each Vuser script you determine the tasks that will be:
Performed by each Vuser
Performed simultaneously by multiple Vusers
Measured as transactions
Step III: Creating the Scenario
A scenario describes the events that occur during a client/server
testing session.
Testing Tools LoadRunner

#4#

A scenario includes a list of machines that host Vusers; a list of Vuser

scripts that the Vusers run; and a list of Vusers that run during the scenario.
You create scenarios using the LoadRunner Controller.
Creating the List of Hosts to Run Vusers
For each scenario, you create a list of hostsmachines configured to
execute Vuser scripts. For each scenario, you create a list of scripts that
Vusers run during scenario execution.
Creating the Vusers
To each Vuser in a scenario, you assign a Vuser script and a host to run
the script.
Step IV: Running the Scenario
You emulate user load on the server by instructing multiple Vusers to
perform tasks simultaneously. You can set the level of load by increasing and
decreasing the number of Vusers that perform tasks at the same time. Before
you run a scenario, you set the scenario configuration. This determines how
all the hosts and Vusers behave when you run the scenario. You can run the
entire scenario, individual Vusers, or groups of Vusers (Vuser Groups). While
a scenario runs, LoadRunner measures and records the transactions that you
defined in each Vuser script.
Step V: Analyzing Test Results
During scenario execution, LoadRunner records the performance of the
client/server system under different loads. You use LoadRunners graphs and
reports to analyze the servers performance.
LoadRunner Vuser Technology
LoadRunner replaces human users with virtual users or Vusers. Vusers
emulate the actions of human users by performing typical business
processes. Each action that a Vuser performs submits input to the
client/server system. By increasing the number of Vusers, you increase the
load on the system. While a workstation accommodates only a single human
user, many Vusers can run concurrently on a single workstation.
To emulate conditions of heavy user load, you create a large number of
Vusers that perform a series of tasks. For example, you can observe how a
server behaves when one hundred Vusers simultaneously withdraw cash
from a banks ATMs. Using LoadRunner, you divide your client/server
performance testing requirements into scenarios. A scenario defines the
Testing Tools LoadRunner

#5#

events that occur during each testing session. Thus, for example, a scenario
defines and controls the number of users to emulate, the actions that they
perform, and the machines on which they run their emulations.
Developing Vuser Scripts
LoadRunner has a variety of Vuser types, each type suited to a
particular load testing environment. This enables you to use Vusers to
accurately model and emulate real world situations. The actions that a Vuser
performs during the scenario are described in a Vuser script. The Vuser
scripts include functions that measure and record the performance of the
server during the scenario. Each Vuser type requires a particular type of
Vuser script. Creating the Vuser scripts required for a scenario is part of the
LoadRunner testing process.
Developing Vuser Scripts - Looking at Vuser Types
LoadRunner provides a variety of Vuser technologies that enable you to
generate
server load when using different types of client/server architectures. Each
Vuser technology is suited to a particular architecture, and results in a
specific type of Vuser. For example, you use RTE Vusers to operate terminal
emulators; TUXEDO Vusers to emulate TUXEDO clients communicating with a
TUXEDO application server; Web Vusers to emulate users operating Web
browsers. The various Vuser technologies can be used alone or together, to
create effective load testing scenarios.
The following table summarizes the use of the various Vuser types:

Testing Tools LoadRunner

#6#

GUI Vusers
GUI Vusers operate graphical user interface (GUI) applications. These
applications can run in either the MS Windows or the X Windows
environments. Each GUI Vuser that you develop emulates a real user by
submitting input to, and receiving output from, GUI applications. For
example, a GUI Vuser could operate Microsoft Paint as follows:
1. Select Open from the File menu.
2. Select a graphic file called test.bmp.
3. Click the Open button.
4. Select Flip/Rotate from the Image menu.
5. Click the Flip Horizontal radio button.
6. Click the OK button.
7. Select Save from the File menu.

Testing Tools LoadRunner

#7#

The operations that a GUI Vuser performs on an application are defined in a

GUI Vuser script. You create GUI Vuser scripts using Mercury Interactives GUI
testing tools: WinRunner (for MS Windows applications), and XRunner and
VXRunner (for X Windows applications).
You can run only a single GUI Vuser on a Windows-based host.
However, Mercury Interactives Virtual X Server technology allows you to
simultaneously run many GUI Vusers on a single UNIX host.
Database Vusers
Database Vusers generate load on a server by submitting input directly
to the server. Database Vusers do not operate client applicationsthey
access the server using LoadRunner API functions. These API functions
emulate the input from an actual application.

Testing Tools LoadRunner

#8#

Because Database Vusers are not reliant on client software, you can use
Database Vusers to test server performance even before the client software
has been developed. Further, because Database Vusers do not have a user
interface, system resources are not used, and you can therefore run large
numbers of Database Vusers on a single workstation.
The following example illustrates the use of Database Vusers: Suppose
that you have a database server that maintains your customer information.
The information is accessed by numerous customer service personnel who
are located throughout the country. The database server receives the
queries, processes the requests, and returns responses to field personnel.
You want to test the response times of the server when numerous service
personnel simultaneously access the server. Using LoadRunner, you could
create several hundred Database Vusers, each Vuser accessing the server
database. The Database Vusers enable you to emulate and measure the
performance of your server under the load of many users. You develop a
Database Vuser script to define the actions of a Database Vuser. A Database
Vuser script includes functions that control the script execution, specify the
input that the Vuser submits to the server, and measure the server
performance.
You develop Database Vuser scripts either by recording with
LoadRunners Vuser Script Generator (VuGen) or by using LoadRunners
Vuser script templates. For the database server example above, you could
create a Database Vuser script that performs the following actions:

Connects to the server

Submits an SQL query
Retrieves and processes the server response
Disconnects from the server

Developing Vuser Scripts

The structure and content of a Vuser script differ from one Vuser type
to another.
For example, Database Vuser scripts always have three sections, are written
in a code that resembles C, and include SQL calls to a database server. In
contrast, GUI Vuser scripts have only one section, and are written in TSL (test
script language). The following diagram outlines the process of developing a
Vuser script.
Testing Tools LoadRunner

#9#

You begin the process of developing a Vuser script by recording a basic

script. LoadRunner provides you with a number of tools for recording Vuser
scripts (see the table below for a list of the tools).
You enhance the basic script by adding control-flow structures, and by
inserting transactions and rendezvous points into the script. You then
configure the run-time settings. The run-time settings include loop, log, and
timing information, and define how the Vuser will behave when it executes
the Vuser script.
To verify that the script runs correctly, you run it in stand-alone mode.
When your script runs correctly, you incorporate it into a LoadRunner
scenario.

Testing Tools LoadRunner

# 10 #

Working with VuGen Introducing VuGen

About VuGen
The Vuser Script Generator, also known as VuGen, is LoadRunners
primary tool for developing Vuser scripts. VuGen is a Windows-based
application that not only records scripts, but also runs them. Running scripts
from VuGen is useful when debugging. It enables you to emulate how a Vuser
script will run when executed in a LoadRunner scenario from the Controller.
Note: VuGen records sessions on Windows platforms only. However, a
recorded Vuser script can run on either a Windows or a UNIX platform. When
you record a Vuser script, VuGen generates and inserts various functions into
the script. These functions include general Vuser functions and
Testing Tools LoadRunner

# 11 #

protocolspecific functions. The general Vuser functions, also known as LR

functions, allow you to obtain information about Vusers running in a scenario.
The protocol-specific functions are specific to the Vuser type. For example,
VuGen inserts LRT functions into a TUXEDO script, and LRS functions into a
Windows Sockets script.
The general Vuser functions and the protocol-specific functions
together form the
LoadRunner API and enable Vusers to communicate directly with a server.
Recording Vuser Scripts with VuGen
You use VuGen to develop a Vuser script by recording a user performing
typical business processes on a client application. VuGen creates the
script by recording the activity between the client and the server. For
example, in database applications, VuGen monitors the client end of the
database and traces all the requests sent to, and received from, the
database server.

Instead of manually creating a Vuser script by programming the

applications API function calls to the server, you use VuGen to:
Monitor the communication between the application and the server
Generate the required function calls
Insert the generated function calls into a Vuser script
VuGen greatly simplifies the task of creating Vuser scripts by reducing the
need for manual programming. Each Vuser script that you create with VuGen
can communicate directly with a server by executing calls to the server API
without relying on client software. You can therefore use Vusers to check
server performance even before the user interface of the client software has
been fully developed.

Testing Tools LoadRunner

# 12 #

In addition, when a Vuser communicates directly with a server, system

resources
are not used on a user interface. This lets you run a large number of Vusers
simultaneously on a single workstation. This in turn allows you to use only a
few testing machines to emulate large server loads.
About Recording with VuGen
VuGen enables you to create a Vuser script by recording actions from
an application. When you run the recorded script, it emulates activity
between the client and server. VuGen eliminates the need to manually
program Vuser scripts. Each Vuser script that you create using VuGen
contains three sections: vuser_init, Actions, and vuser_end. During recording,
you can select the section of the script into which VuGen will insert the
recorded functions.
In general, you record a log in to a server into the vuser_init section;
client activity into the Actions section; and the logoff procedure into the
vuser_end section. While recording, you can insert transactions and
rendezvous points.
Creating a Vuser Script
Before you begin recording, you must create a Vuser script. If you are
recording a Java, Baan, or RTE application, you can also record into an
existing script.
To create a new Vuser script:
Start VuGen.
Select Start > Programs > LoadRunner > Virtual User Generator.
Testing Tools LoadRunner

# 13 #

The VuGen window opens.

Recording with VuGen

Click the New button. The New Virtual User dialog box opens with a list
of the supported Vuser script types.

Select a Vuser script type and then click OK.

Recording Vuser Scripts
The recording procedure differs slightly between protocols. For Baan
and Java
Vusers. For all other Vusers types, see the section below.
To record for APPC, Database, TUXEDO, or Windows Socket Vusers:
If the Start Recording dialog box is not open, click the Start Recording
button. The Start Recording dialog box opens.
Testing Tools LoadRunner

# 14 #

 Specify an application to record. To locate your application, click

Browse to the right of the Program to Record box.
Note that you can add command line parameters to your application by
filling them in manually in the Program to Record box, to the right of the
application name. For example: starts plus32.exe, and connects the user
Peter to the server Neptune.
Specify a working directory for your application.
In the Start Recording into Section box, select the section in which you
want to begin recording. The available sections are vuser_init, Actions,
and vuser_end.
Click OK to begin recording. VuGen starts your application and the
Recording toolbar appears.

Perform typical actions within your application. To switch sections

during recording, use the floating toolbar.
f:\orant\bin\plus32.exe peter@neptune
After recording typical user actions, select the vuser_end section from
the floating toolbar.

Testing Tools LoadRunner

# 15 #

 Perform the log off procedure. VuGen records the procedure into the
vuser_end section of the script.
Click Stop Recording on the Recording toolbar. The main VuGen window
displays all the recorded statements.

Click Save to save the recorded session. The Save As dialog box opens
(for new Vuser scripts only). Specify a script name.
After recording a script, you can manually edit the script in VuGens
main window. VuGen creates a series of configuration, data, and source code
files during recording . These files are used to execute the Vuser actions. You
can display the contents of each of these sections in the main VuGen
window. You can display the contents of only a single section at a time. To
display a section, highlight its name in the Sections box.
Enhancing Vuser Scripts
When you create a Vuser script, you can enhance its capabilities by adding
Vuser functions. For example, you can add debugging code, or functions that
Testing Tools LoadRunner

# 16 #

retrieve runtime information about the Vusers participating in the scenario.

VuGen helps you generate most of the Vuser functions by recording from
your applicationother functions you must manually type into the Vuser
script.
LoadRunner provides several libraries whose functions enhance a
script. You can use general Vuser functions or functions from the library
specific to your applicationsuch as Oracle, CtLib, ODBC, TUXEDO, Web, or
Windows Sockets. In addition, you can enhance your Vuser script with
standard ANSI C functions.
Inserting Transactions
You define transactions to measure the performance of the server.
Each transaction measures the time it takes for the server to respond to
specified Vuser requests. These requests can be simple tasks such as waiting
for a response for a single query, or complex tasks, such as submitting
several queries and generating a report. To measure a transaction, you insert
Vuser functions to mark the beginning and end of a task. Within a script, you
can mark an unlimited number of transactions for analysis, each with a
different name. During scenario execution, the Controller measures the time
that it takes to perform each transaction. After the scenario run, you analyze
the servers performance per transaction using LoadRunners graphs and
reports.
To mark the start of a LoadRunner transaction:
While recording a Vuser script, click the Start Transaction button on the
Recording toolbar. The Start Transaction dialog box opens.

Type a transaction name in the Name box. Click OK to accept the

transaction name. LoadRunner inserts an lr_start_transaction
statement into the Vuser script. For example, the following function
indicates
the
start
of
the
trans1
transaction:
lr_start_transaction(trans1);
To mark the end of a transaction:
While recording a script, click the End Transaction button on the
Recording toolbar. The End Transaction dialog box opens.
Testing Tools LoadRunner

# 17 #

 Click the arrow for a list of open transactions. Select the transaction to
close. Click OK to accept the transaction name. LoadRunner inserts an
lr_end_transaction statement into the Vuser script. For example, the
following function indicates the end of the trans1 transaction:
lr_end_transaction(trans1, LR_AUTO);
Inserting Rendezvous Points
To emulate heavy user load on your client/server system, you
synchronize Vusers to perform a task at exactly the same moment. You
ensure that multiple Vusers act simultaneously by creating a rendezvous
point. When a Vuser arrives at the rendezvous point, it is held by the
Controller until all Vusers participating in the rendezvous arrive. When the
rendezvous conditions are met, the Vusers are released by the Controller. You
designate the meeting place by inserting a rendezvous point into your Vuser
script. When a Vuser executes a script and encounters the rendezvous point,
script execution is paused and the Vuser waits for permission from the
Controller to continue. After the Vuser is released from the rendezvous, it
performs the next task in the script.
To insert a rendezvous point:
While recording a Vuser script, click the Rendezvous button on the
Recording toolbar. The Rendezvous dialog box opens.

Type a name for the rendezvous

accept the rendezvous name.
statement into the Vuser script.
defines
a
rendezvous
lr_rendezvous(rendezvous1);
Testing Tools LoadRunner

point in the Name box. Click OK to

VuGen inserts an lr_rendezvous
For example, the following function
point
named
rendezvous1:

# 18 #

Inserting Comments
VuGen allows you to insert comments between Vuser activities. You
can insert a comment to describe an activity or to provide information about
a specific operation. For example, if you are recording database actions, you
could insert a comment to mark the first query, such as This is the first
query.
To insert a comment:
While recording a script, click the Comment button on the Recording
tool bar. The Insert Comment dialog box opens.

Type the comment into the text box.

Click OK to insert the comment and close the dialog box. The text is
placed at the current point in the script, enclosed by comment
markers. The following script segment shows how a comment appears
in a Vuser script:
Note: You can insert comments into your script even after you complete a
recording session, by selecting Insert > Comment from the VuGen menu.
/*
* This is the first query
*/
LoadRunner Controller
To open the Controller:
Select Start > Programs > LoadRunner > Controller.
The Controller window opens with the LoadRunner Controller dialog box
inside.
Testing Tools LoadRunner

# 19 #

The LoadRunner Controller dialog box includes the following options:

Wizard: Creates a scenario with the aid of the LoadRunner Scenario wizard,
an interactive, step-by-step guide to creating a scenario.
New: Creates a new scenario.
Open an existing scenario: Opens an existing scenario.
Show at Startup: If you do not want this window to appear the next time
you start LoadRunner, clear the Show at Startup check box. Once you clear
this checkbox, when you open the Controller, the window layout from the last
time you worked with the Controller appears.
Introducing LoadRunner Controller
The LoadRunner Controller window contains the following elements:
Title bar Displays the name of the scenario on which you are currently
working.
Menu bar Displays the menus from which you select commands.
Tool bar Provides shortcuts for selecting commands. Clicking on a button
executes a command.
Status bar Provides information on the current state of the scenario.
Vuser window Displays a list of all the virtual users that can take part in the
scenario. You also create Vusers using this window.

Testing Tools LoadRunner

# 20 #

Understanding LoadRunner The LoadRunner Controller at a Glance

The following five icons appear at the bottom of the Controller window. Click
an icon to display the corresponding window inside the Controller.
Host window Displays the list of machines that can execute Vuser scripts
during the scenario.
Script window Displays a list of all the Vuser scripts that you can assign to
Vusers.
Rendezvous window Displays the Vusers that simultaneously perform
tasks during the scenario.
Output window Displays error and notification messages generated by
Vusers during scenario execution.
Transaction window Displays all the transactions that will be measured
during scenario execution.
Selecting LoadRunner Commands
You select LoadRunner commands from the menu bar or on the toolbar.
Choosing Commands from a Menu
You select LoadRunner commands from the menus on the menu bar.
Some commands use standard Microsoft Windows shortcut conventions.

Testing Tools LoadRunner

# 21 #

Choosing Commands from the Toolbar

You can execute many LoadRunner commands by clicking a button on
the toolbar in the LoadRunner Controller.

A scenario describes the events that occur during each load testing
session. A scenario contains lists of hosts, Vusers, Vuser scripts, transactions,
and rendezvous points. You create a scenario using the LoadRunner
Controller. After you create the scenario, LoadRunner saves the information
in a scenario file (. lrs). You use the commands in the File menu to create,
open, save, and close scenario files. Some of these commands are available
from the toolbar.
Creating a New Scenario
The New command creates a completely new scenario. Note that the
New command clears all the information displayed in the Controller windows.
To create a new scenario, choose File > New, or click the New button.
You can also create a new scenario by using the Scenario wizard. The
wizard is an interactive, step-by-step guide to creating a scenario. To create a
new scenario by using the Scenario wizard, select File > Scenario Wizard.
Opening an Existing Scenario
The Open command opens any existing scenario.
To open an existing scenario:
Choose File > Open, or click the Open button. The File Open dialog box
opens.

Testing Tools LoadRunner

# 22 #

 Click a file in the File Name list or type a file name in the File Name
box.
Click OK. The File Open dialog box closes and the scenario appears in
the LoadRunner Controller.
Saving a Scenario
The Save command saves the current scenario.
Closing a Scenario
Closing a scenario closes all the Controller windows. To close the
scenario, choose File > Close. If you made changes to the scenario, a Save
Changes message appears. Choose Yes to save the changes you made. All
open windows and icons in the Controller close.
Filtering and Sorting Information
Each window in the LoadRunner Controller displays information about
the scenario. You can filter and sort the information that appears in each
window. Filtering information displays only those items that meet the
selected criteria. For example, you can filter the Vuser window to display only
those Vusers that are in the READY state. Sorting information displays all
the items in a list in a certain order. For example, you can sort all Vusers in
the Vuser list, in order of their Vuser ID number (1,2,3 etc.).
This section describes how to filter and sort the information displayed in the
Vuser window. Note that you cannot filter or sort the transactions displayed
in the Transaction window.
Testing Tools LoadRunner

# 23 #

Filtering Information
You use the Filters box to filter the information that appears in a
window. There is a Filters box in the toolbar in each window.

To filter information:
Click the arrow on the Filters list. The list of available filters appears.

Click a filter in the list. The information in the window is filtered.

Sorting Information
You use the Sort list to sort the information that appears in a window.
There is a
Sort box in the toolbar in each window.
Create a Scenario
To develop a scenario, you create a host list, a script list and a Vuser
list. This describes how to create a host listthe list of machines, or hosts,
that execute Vuser scripts during a scenario run.
Testing Tools LoadRunner

# 24 #

Creating a Host List

Hosts are the machines on which Vusers run their scripts. The host list
displays the machines that can run Vusers during scenario execution. You
can add both UNIX and Windows machines to the host list. The Host window
displays the host list and the following information for each host:
The status of the host
The platform type of the host (UNIX or Windows)
Details of the scenario that is currently running
The Host window has its own menu in the Controller menu bar, and a tool
bar that lets you create and manage the host list.

The following procedure outlines how to create a host list for a

scenario:
Install a LoadRunner remote command launcher on every
machine (except for local host) you want to use as a host.
The remote command launcher is an application that enables the
Controller to invoke applications on the host. For more information
about installing LoadRunner remote command launchers, refer to the
Installing LoadRunner guide.
Add the names of the hosts to the host list.
Set attributes for each host (optional).
Host attributes specify the number and type of Vusers that can run on
each host.
For example, you can set the maximum number of DB Vusers a host
can run.
Select which hosts will take part in the scenario (optional).
Testing Tools LoadRunner

# 25 #

Each time you run a scenario, some hosts may be unavailable. You can
temporarily remove (disable) hosts from the list.
Creating a Scenario Creating a Host List
Adding a Host to the Host List
You use the Host window in the LoadRunner Controller to add hosts to the
host list. After you create a host, you can set and modify the attributes for
the new host.
To add a host to the host list:
Start the LoadRunner Controller and open the Host window. The Host
menu appears in the LoadRunner menu bar.
Choose Host > Add. The Host Information dialog box opens.

Type the name of the host in the Name box.

Click a platform in the Platform list (UNIX or Windows).
Testing Tools LoadRunner

# 26 #

 By default, LoadRunner stores temporary files on the host during

scenario execution in a temporary directory specified by the hosts
TEMP or TMP environment variables. To override this default for a
specific host, type a location in the Temporary Directory box.
If the host is UNIX-based, set the login information for the host. By
default, LoadRunner uses your NT user name for the UNIX login. In
other words, if your NT login is lrunner, the Controller will log on to the
host as lrunner. You can also specify to login to the UNIX machine as
another user.
7 Click OK to close the Host Information dialog box. The host name you
entered appears in the Host window; the host status is set to DOWN.
Modifying Host Attributes
Host attributes determine:
The maximum number of Vusers that a host runs
The initialization quota for a host
The location of the WinRunner configuration file (for GUI Vusers)
The location of the files during run-time
Setting the Maximum Number of Vusers that a Host Can Run
You can increase or decrease the maximum number of GUI, DB and RTE
Vusers that a host can run. You modify the maximum number according to
the available resources, the needs of your scenario, and your LoadRunner
license agreement.
To set the maximum number of Vusers that a host can run:
Open the Host window. The Host menu appears in the LoadRunner
menu bar.
Click a host in the Host window. The host is highlighted.
Choose Host > Details. The Host Information dialog box opens.

Testing Tools LoadRunner

# 27 #

 Click the Vuser Types tab.

In the Maximum Active boxes enter the maximum number of Vusers of

each type that the host can run. The maximum number of active
Vusers that you specify must not exceed the number of Vusers that you
are licensed to run. To check your Vuser licensing limitations, choose
Help > About LoadRunner.
Click OK to close the Host Information dialog box.
Setting the Initialization Quota
The initialization quota determines how many Vusers a host initializes
at a time. Initializing a large number of Vusers simultaneously places large
stress on a host. To reduce stress on a host, you can initialize smaller batches
of Vusers.
Testing Tools LoadRunner

# 28 #

To set the initialization quota:

Open the Host window. The Host menu appears in the LoadRunner
menu bar.
Click a host in the Host window. The host is highlighted.
Choose Host > Details. The Host Information dialog box opens.
Click the Vuser Types tab.
In the Initialization Quota boxes, enter the maximum number of Vusers
of each type that the host will initialize simultaneously.
Click OK to close the dialog box.
Setting the Location of the WinRunner Configuration File
A GUI Vuser, running on a Windows-based host, uses WinRunner to
execute its Vuser script. To enable the LoadRunner Controller to open
WinRunner, you specify the location of the appropriate WinRunner
configuration file ( wrun.ini). To specify the location, you can:
Use the default configuration file for the scenario.
Specify another configuration file for all Vusers on a certain hostall
the Windows
GUI Vusers running on the specified host will access this file.
To select the location of WinRunner for a GUI Vuser:
Open the Host window. The Host menu appears in the LoadRunner
menu bar.
Click a host in the Host window. The host entry is highlighted.
Choose Host > Details. The Host Information dialog box opens.
Click the WinRunner tab, and then click one of the following options:
Scenario Default: Instructs the Vuser to use the WinRunner
configuration file specified in the Scenario Configuration dialog box.
Local Configuration File: Instructs the Vuser to use the hosts
WinRunner configuration file.
Path: Instructs the Vuser to use the WinRunner configuration file that
is in a specific location on the network. To specify the path of the
configuration file, click the browse button to the right of the Path box,
and then set the location using the Choose WinRunner Configuration
File dialog box.
Click OK. The Host Information dialog box closes.
Testing Tools LoadRunner

# 29 #

Specifying where a Host Saves Files During Run-Time

When a host runs a Vuser script, the Vuser generates results that
describe the execution of the script. By default, these results are saved
temporarily on a local drive of each hostuntil they are collated by the
Controller to a central location. Alternatively, you can select to save the
results directly to a shared network drive. The way in which the scenario
results are saved is set globally for all the hosts in the scenario, you can
change the way in which individual hosts save their results.
To change how individual hosts save their results:
Open the Host window. The Host menu appears in the LoadRunner
menu bar.
Click a host in the Host window. The host entry is highlighted.
Double-click the host or choose Host > Details. The Host Information
dialog box appears. Ensure that the Runtime File Storage tab is visible.

To store the scenario results on a shared network drive, click On a

shared network drive, and then select the Results check box. This
option overrides the setting for the scenario.
To store the results temporarily on a hard drive of the host computer,
click On local host. The temporary result files will be stored under the
temporary directory specified by the hosts environment variables (on
Testing Tools LoadRunner

# 30 #

Windows, TEMP or TMP and on UNIX, $TMPDIR or $TMP). This option

overrides the setting for the scenario. These temporary results are
deleted either when the agent goes down or when you run the scenario
again.
To store the scenario results according to the scenario default, click
Scenario default. This is the default setting.
Click OK to close the dialog box.
Selecting the Hosts for a Scenario
Before you run a scenario, you can select which hosts will run Vusers.
This compensates for the possibility that some hosts will be unavailable. For
example, a machine may already be in use when you want to run the
scenario. You select which hosts will take part in the scenario by using the
Enable and Disable commands. Disabling a host temporarily removes it from
the list. Enabling a host reinstates it.
Disabling Hosts
When you disable a host, the host will not execute Vuser scripts during
a scenario execution.
To disable a host:
Open the Host window. The Host menu appears in the LoadRunner
menu bar.
Click a host in the Host window. The host is highlighted.
Click the Disable button or choose Host > Disable. The host name
changes from black to gray. The host is disabled.
Enabling Hosts
Enabling a host reinstates a previously disabled host.
To enable a host:
Click a disabled host in the Host window. The host is highlighted.
Click the Enable button or choose Host > Enable. The host name
changes from gray to black, and the host is enabled.
Creating a Script List

Testing Tools LoadRunner

# 31 #

To develop a scenario, you create a host list, a script list, and a Vuser
list. This describes how to create a script listthe list of all the Vuser scripts
that Vusers can run during scenario execution.
About Creating a Script List
A Vuser script defines the actions that a Vuser performs during
scenario execution. The script list contains all the Vuser scripts that Vusers
can run. The script list may contain scripts for GUI, DB, and RTE type Vusers.
The Script window, which displays the script list, has its own menu in the
Controller menu bar. The Script window includes the following information for
each script in the list:

The name of the Vuser script

The type of Vuser that will run the script
The location (path) of the script
Command line options associated with the script

Adding a Script to the Script List

You use the Script window in the LoadRunner Controller to add scripts
to the script list. After you create a script, you can set and modify the details
of the new script.
When you add a script to the script list, ensure that the Controller can
recognize the scripts path. During run time, the Controller sends a copy of
the scripts to the Vuser hosts.
To add a script to the script list:
Start the LoadRunner Controller and open the Script window. The Script
menu
appears in the LoadRunner menu bar.

Testing Tools LoadRunner

# 32 #

 Choose Script > Add. The Vuser Script Information dialog box opens.

Click the browse button to the right of the Path box. The Open dialog
box appears.
In the Files of Type box select the Vuser type, and then select the
path and file name of the new script.
Click Open to select the files. The Open dialog box closes, and the new
script name and its Vuser type appear in the Vuser Script Information
dialog box.
In the Command Line box, type any command line options to use when
running the script. For example: -x value -y value
To see the transactions declared in the selected script, click the
Transaction tab.
Testing Tools LoadRunner

# 33 #

 To see the rendezvous points declared in the selected script, click

the Rendezvous tab.
To see the list of Vusers associated with the selected script, click
the Vusers tab. If you have not yet created Vusers, the box will
be empty.
To see the list of data tables used by selected script and the
global data directory, click the Data Tables tab.
To see the list of files used by the selected script, click the Files
tab. This list includes all files which make up the Vuser script,
including the configuration settings file, the init, run and end
portions of the script, the parameterization definitions file and
the user file.

Click OK to close the Vuser Script Information dialog box.

The new script name and its details appear in the Script window.

Modifying Script Details

You can modify the details of a script in the script list using the Vuser
Script Information dialog box.
To modify the details of a script in the script list:
Start the LoadRunner Controller and open the Script window. The Script
menu appears in the LoadRunner menu bar.
Click a script in the Script window. The script is highlighted.
Choose Script > Details. The Vuser Script Information dialog box opens,
displaying the details of the selected script.
Modify the details as necessary. Note that you cannot modify the
transactions, rendezvous, or Vusers associated with a script.
Click OK to close the Vuser Script Information dialog box and save the
changes. The modified script details appear in the Script window.
You can customize the way that the Controller executes a Vuser script by
configuring the scripts run-time settings. You can modify these settings
using the LoadRunner Controller by choosing Script > Runtime Settings. You
can also modify the settings using the Vuser Script Generator (VuGen). The
run-time settings can be set in the following areas: Think Time, Iterations,
Log, and Web.
Creating a Vuser List
To develop a scenario, you create a host list, a script list, and a Vuser
list. This describes how to create the Vuser listthe list of all the Vusers that
can run during scenario execution.
Testing Tools LoadRunner

# 34 #

About Creating the Vuser List

With LoadRunner, you test your client/server system by creating and
running scenarios. A scenario describes the events that occur during a
client/server load testing session. Each scenario contains a list of many
virtual users (Vusers). Vusers emulate human users interacting with your
client/server system. When you run a scenario, the Vusers generate load on
the server, and LoadRunner monitors the servers performance. For example,
to test a bank server you could create Vusers that deposit and withdraw cash
using automatic teller machines (ATMs). LoadRunner would monitor the bank
servers performance while varying numbers of customers simultaneously
perform deposit and withdrawal operations.
Creating the Vuser List
You create the Vuser list in the Vuser window. The Vuser window has a
menu in the LoadRunner menu bar, and a tool bar that lets you create and
manage the Vuser list. You can also use the Vuser window to control Vusers
while running a scenario.
The following procedure outlines how to create a Vuser list:
Create the Vusers.
For each Vuser, you select the script the Vuser runs and a host to run
the script.
Schedule the Vusers (optional).
You can set scheduling attributes for each Vuser. These attributes
determine the order and time each Vuser runs during scenario
execution.
Organize the Vusers into Vuser Groups.
You can use Vuser Groups to organize Vusers into manageable groups.
For example, you can create a Vuser Group that contains Vusers of the
same type or that run the same script.
Creating Vusers
You create a Vuser by specifying the Vuser script that the Vuser will
run, and a host to run the script. You can assign the same Vuser script to
many Vusers.
Note: The type of Vuser script that you select determines the type of Vuser
created: selecting a DB Vuser script creates a DB Vuser; selecting a GUI
Testing Tools LoadRunner

# 35 #

Vuser script creates a GUI Vuser; selecting an RTE Vuser script creates an RTE
Vuser.
To create Vusers:
Start the LoadRunner Controller, display the Vuser window, and click in
the Vuser side of the window. The Vuser menu appears in the
LoadRunner menu bar.
Choose Vuser > Add. The Vuser Information dialog box appears.

In the Quantity box, enter the number of Vusers that you want to
create.
Select a host in the Host Name list. Select New to open the Host
Information dialog box and add a host to the list.
Select a script in the Script Name list. To see the rendezvous points and
transactions defined in the Vuser script, click the Script tab. To add a
new script to the list, click New to open the Vuser Script Information
dialog box.
Click OK to close the Virtual User Information dialog box. The new
Vusers appear in the Vuser window. LoadRunner assigns unique ID
numbers to the Vusers. If you did not create a Vuser Group,
LoadRunner creates the Vuser Group G1 and assigns the Vusers to it.
Testing Tools LoadRunner

# 36 #

Scheduling Vusers
After you create a Vuser, you can schedule the Vuser by setting:
The earliest time the Vuser can run
The amount of time after the scenario has begun that the Vuser will
start running

To schedule a Vuser:
Open the Vuser window, and click in the Vuser side of the window. The
Vuser menu appears in the LoadRunner menu bar.
Choose Vuser > Details. The Vuser Information dialog box appears.
Click the Scheduling tab.

Set one of the following scheduling options:

Not Before Time The earliest time the Vuser will run.
Testing Tools LoadRunner

# 37 #

With Delay of The amount of time (in minutes) after the

scenario has begun that the Vuser will start running.
Click OK to close the dialog box.

Creating Vuser Groups

You can use Vuser Groups to organize the Vusers in a scenario into
manageable groups. You create Vuser Groups that contain Vusers with shared
or similar characteristics. For example, you can create a Vuser Group for all
Vusers that run the same Vuser script.
To create a Vuser Group:
Open the Vuser window. The Vuser menu appears in the LoadRunner
menu bar.
Click anywhere in the Vuser Group column. The Vuser Group menu
appears in the LoadRunner menu bar.
Choose Group > Add. The Vuser Group Information dialog box opens.

In the Name box, enter the name of the Vuser Group and then click OK.
The new Vuser Group appears at the bottom of the Vuser Group list in
the Vuser window.
In the Command Line box, type any command line options to use when
running the group. For example: -x value -y value
Note: At run time, the Group command line options will be joined together
with any Vuser script command line options. If the Group and the script
specified the same option with different values, then the value defined for
the Group is used.
Testing Tools LoadRunner

# 38 #

Note: When you renumber Vusers, the Vusers are assigned new ID numbers.
This may conflict with previous results.
To renumber the Vusers within a Vuser Group:
Select the Vuser Group that you want to renumber.
Choose Group > Renumber. The Vusers in the selected group are
renumbered from 1.

Scheduling Vuser Groups

After you create a Vuser Group, you can schedule the group by setting:
The amount of time after the start of the scenario that the group must
wait before it starts running
The amount of time the group will run
To schedule a Vuser Group:
Open the Vuser window, and click in the Vuser Group (left) side of the
window. The Group menu appears in the LoadRunner menu bar.
Choose Group > Details. The Group Information dialog box opens.

Set one or both of the following scheduling options:

Testing Tools LoadRunner

# 39 #

Start Delays the start the Vuser Group when you run a scenario.
You enter the delay time in minutes. Note that if you delay the
start of a specific Vuser (via the Vuser Information dialog box),
the Vuser delay begins only after any Vuser Group delay time has
passed.
Run for Runs all the Vusers in the Vuser Group for a specified
amount of time from when the Vuser Group started. You enter
the time in minutes.
Click OK to close the dialog box.

Running the Scenario

You run a scenario in order to check response times of your
client/server system under load. To accurately emulate a real-world situation,
you can use rendezvous points to cause multiple Vusers to perform tasks at
exactly the same time, thereby creating intense user load on the server. To
further improve the way that your scenarios emulate real-world situations,
you can configure some of the scenario execution parameters. When you run
a scenario, LoadRunner generates load on the client/server system, and
measures the systems performance.
About Running a Scenario
When you run a scenario, the Vusers are assigned to their hosts and
execute their Vuser scripts. During scenario execution, LoadRunner:
Records the durations of the transactions you defined in the Vuser
scripts
Performs the rendezvous in the rendezvous list
Collects error and notification messages generated by the Vusers
You can run an entire scenario unattended, or you can interactively
select the Vuser Groups and Vusers that you want to run. When the scenario
starts running, the Controller first checks the scenario configuration
information. Next, it invokes the applications that you selected to run with
the scenario. Then, it distributes each Vuser script to its designated host.
When the Vusers are ready, they start executing their Vuser scripts. While
the scenario runs, you can pause and stop individual Vuser Groups and
Vusers. The scenario ends when all the Vusers have completed their Vuser
scripts, when the duration runs out, or when you terminate it.
The following procedure outlines how to run a scenario:
Open an existing scenario or create a new one.
Configure the scenario.
Testing Tools LoadRunner

# 40 #

 Set the results directory.

Run and monitor the scenario.
While the scenario runs, you can pause and stop individual Vuser Groups and
Vusers; monitor each Vuser in the scenario; and view error and notification
messages generated by the Vusers
Running an Entire Scenario
You can run all the Vusers in a scenario, or you can select the specific Vuser
Groups and Vusers that you want to run. This section describes how to run an
entire scenario.
To run an entire scenario:
Open an existing scenario or create a new one.
Choose Scenario > Start, or click the Start button. The Controller starts
initializing the Vusers and distributing them to their designated hosts
where they begin to execute their Vuser scripts. If you have not
specified a results directory for the scenario, the Set Results File dialog
box opens. During scenario execution you can manipulate individual
Vusers and Vuser Groups in the scenario.
Choose Scenario > Stop, or click the Stop button to terminate the
scenario.
Controlling Individual Vusers and Vuser Groups
You can run an entire scenario as described above, or you can
manipulate individual Vusers in the scenario. This section describes how to
initialize, run, pause, and stop Vusers.
Initializing Vusers
Initializing a Vuser distributes the Vuser to its designated host so that
the Vuser is ready to execute its script.
To initialize a Vuser:
Select the Vuser Groups or Vusers that you want to initialize.
Choose Vuser > Initialize or Group > Initialize, or click the Initialize
button. The Vusers status changes from DOWN to PENDING to
INITIALIZING to READY. If a Vuser fails to initialize, the Vuser status
changes to ERROR.
Running Vusers
Testing Tools LoadRunner

# 41 #

Running a Vuser tells the Vuser to execute its script.

To run a Vuser:
Select the Vuser Groups or Vusers that you want to run.
Choose Vuser > Run or Group > Run, or click the Run button. The
Vusers execute their scripts. If you run a Vuser in the DOWN or ERROR
state, LoadRunner initializes and then runs the Vuser.
Pausing Vusers
Pausing a Vuser temporarily stops script execution. The Pause
command changes the status of a Vuser from RUNNING to PAUSE.

To pause a Vuser:
Select the Vuser Groups or Vusers that you want to pause.
Choose Vuser > Pause, or click the Pause button. The Vusers are
paused.
Stopping Vusers
Stopping a Vuser stops script execution. If you stop a Vuser, the Vuser
still appears in the Vuser list.
To stop a Vuser:
Select the Vuser Groups or Vusers you want to stop.
Choose Vuser > Stop, or click the Stop button. The Vusers stop
executing their scripts.
Manually Releasing Vusers from a Rendezvous
While you run a scenario, you can manually release Vusers from a
rendezvous
before the Controller releases them.
To manually release Vusers from a rendezvous:

Testing Tools LoadRunner

# 42 #

 Open the Rendezvous window. The Rendezvous menu appears in the

LoadRunner menu bar.
Click a rendezvous in the Rendezvous window.
Choose Rendezvous > Release, or click the Release button. The Vusers
in the rendezvous are released.
Monitoring Vusers
During scenario execution, you can use the Vuser window to monitor
the actions of all the Vusers in the scenario. This section describes how to
monitor Vusers running on Windows-based and UNIX platforms. In addition to
monitoring UNIX Vusers, you can view the actions that they perform. While a
scenario is running you can monitor the state of each Vuser. The Status field
of each Vuser displays the current state of the Vuser. The following table
describes all possible Vuser states.

Testing Tools LoadRunner

# 43 #

You can display scenario statistics by expanding the Vuser window. This
allows you to see how many Vusers in each Vuser Group are in the DOWN,
PENDING, INITIALIZING, READY, RUNNING, PAUSED, and RENDEZVOUS states.

To expand the Vuser window:

Choose Vuser > Show Group Totals, or click the Show Totals button.
To Hide the scenario statistics:
Choose Vuser > Hide Group Totals, or click the Hide Totals button.
Viewing Scenario Execution Messages
While the scenario runs, the Vusers and hosts send error and
notification messages to the Controller. You can view these messages in the
Output window. The messages in this window are cleared at the start of
scenario execution.
Testing Tools LoadRunner

# 44 #

The Output window also displays:

The
The
The
The
The

time each message arrived

type of message sent
Vusers host
ID of the Vuser that sent the message
text of the message

To view more details about a Vuser who sent a message:

Highlight a message from a Vuser in the Output window and choose
Output > Vuser Details to see the Vuser information, or choose Output >
Show Vuser Log to see the Vusers output log file.
To limit the number of messages that are displayed in the Output
window:
Choose Options > Settings. In the Output tab, select Limit the number
of output messages to and specify the number of messages.
To save scenario execution messages:
Choose Output > Export To File, or click the Export button. The Output
messages are saved to a file.
To clear scenario execution messages:
Choose Output > Remove All, or click the Remove All button. The
Output window is cleared of all messages.
Analyzing Test Results, Understanding LoadRunner Analysis
After running a scenario, you can use LoadRunners graphs and reports
to analyze the performance of your client/server system.
Testing Tools LoadRunner

# 45 #

Working with Analysis Reports

In order to view a report, you must generate the report from the
LoadRunner Analysis window. LoadRunner reports are displayed in a Report
Viewer. You can print, save, or export the data using the viewer.
Selecting and Displaying Reports
When you run a scenario, LoadRunner stores the scenario results in the
specified directory. When you run the analysis, LoadRunner processes the
data and formats them into a database. The formatted data is used to
generate reports and graphs. You can instruct LoadRunner to run the analysis
automatically at the end of a scenario by selecting Results > Auto Load
Analysis.
To display reports:
Select Results > Analyze Results, or click the Analysis button. The
Analysis window opens.
From the Reports menu choose a report. The report is generated and
displayed. You can display multiple copies of the same report.
The Report Viewer
Each report is displayed in its own report viewer. Each viewer contains
a header
and a toolbar.

Report Header
The header displays general scenario information.

Testing Tools LoadRunner

# 46 #

The report header contains the following information:

Title: The name of the report.
Scenario: The name of the scenario described in the report.
Result: The pathname of the scenario results directory.
Start time: The time at which the Run Scenario command was executed.
End time: The time at which the scenario script was terminated.
Duration: The total run time of the scenario.
Report Viewer Toolbar
Each report viewer has a toolbar that lets you perform operations on
displayed reports.

The report viewer toolbar contains the following buttons:

Zoom: Toggles between an actual size, full page, and magnified views of the
report.
Print: Prints the displayed report.
Export to file: Exports the displayed information to a disk file.
Export to mail: Mails the displayed information using Microsoft Mail.
Analysing Scenario activity
After running a scenario, you can analyze the Vuser activity that
occurred during the scenario to check that the scenario ran as planned.
About Scenario Activity
During scenario execution, Vusers generate data as they perform
transactions. LoadRunner enables you to generate graphs that show scenario
activity or overall scenario performance. Scenario activity graphs and reports
let you track Vuser behavior throughout the scenario. The graphs map the
transactions, rendezvous, and active status of the Vusers, according to the
elapsed scenario time. When working with graphs, you can focus on specific
segments of the scenario using the zoom tools. In addition, you can change
the granularity of the graph.
Testing Tools LoadRunner

# 47 #

Running Virtual Users Graph

The Running Virtual User graph displays the number of Vusers that
executed Vuser scripts during each second of a scenario run. Only Vusers in
the RUNNING and RENDEZ states are included in the graph. Vusers in the
LOADING, READY and PAUSE states are not displayed.

This graph is useful for determining the Vuser load on your server at any
given moment. The x-axis represents the elapsed time (in seconds) since the
start of the scenario run. The y-axis represents the number of running Vusers
in the scenario. For example, the above graph indicates that there was a
maximum load of thirty Vusers. Until the 37th second of the scenario run,
Vusers were gradually loading. Thereafter, the number of running Vusers
decreased to twenty, and then to ten.
Rendezvous Graph and Report
The Rendezvous graph indicates when Vusers were released from
rendezvous points, and how many Vusers were released at each point. This
graph helps you understand transaction performance times. If you compare
the Rendezvous graph to the Transaction Performance graph, you can see
how the load peak created by a rendezvous influences transaction times.

Testing Tools LoadRunner

# 48 #

On the Rendezvous graph, the x-axis indicates the number of seconds

that elapsed since the start of the scenario run. The y-axis indicates the
number of Vusers that were released from the rendezvous. If you set a
rendezvous for 60 Vusers, and the graph indicates that only 20 were
released, you can see that the rendezvous ended when the timeout expired
because all of the Vusers did not arrive. In the above Rendezvous graph, the
first query rendezvous takes place during the 312th second of the scenario,
and 60 Vusers were released. By comparing these results to the Transaction
Performance graph, you see that the peak time for the query transaction
occurred under the load of sixty Vusers, with a response time of 20 seconds.

The Rendezvous report provides additional information about

the rendezvous.
Redezvous First arrival time Release time
Reason
Query_md
Time out

11:54:11

Testing Tools LoadRunner

11:55:06

Members
50

Released
40

# 49 #

Query_md
Vuser
Query_md
OK
Query_md
Time out

11:55:11

11:55:42

50

10

11:55:43

11:56:01

50

50

11:56:19

11:57:21

50

48

by

In the above report, the rendezvous policy was set to All Arrived,
requiring all 50 Vusers to arrive at the rendezvous point. In the first
rendezvous, 40 Vusers were released after the timeout period while 10
Vusers were manually released by the operator. In the next rendezvous, all
50 Vusers arrived. In the last rendezvous, two Vusers never arrived, causing
the others to reach the timeout.
Transactions per Second Graph (Passed)
The Transactions per Second (Passed) graph displays the number of
completed, successful transactions performed during each second of a
scenario run. This graph helps you determine the actual transaction load on
your system at any given moment. You can compare this graph to the
Transaction Performance graph in order to analyze the effect of the number
of transactions on the performance time.

Testing Tools LoadRunner

# 50 #

The x-axis represents the elapsed time (in seconds) since the start of
the scenario run. The y-axis represents the number of transactions
successfully performed during the scenario run. For example, the above
graphs indicate that in the 224 th second of the scenario, nine query
transactions were successfully completed. The response time at that point
was 49 seconds.
Failed Transactions Graph and Report
The Transactions per Second (Failed) graph displays the number of
completed, unsuccessful transactions performed during each second of the
scenario run. This graph contains information about transactions that were
assigned an LR_FAIL value in the lr_end_transaction statement.
Note: The lr_end_transaction statement must be executed in order to
generate the Failed Transaction graph. If your program aborts immediately
upon an error, all current transactions are terminatedno data is generated
for failed transactions.
The following example uses a Web Vuser script. Web Vuser statements return
zero for success and a positive value for failure. The Web Vuser script below
tries to access an HTML page using a GET statement. If the GET request
succeeds, the script assigns the LR_PASS status to the transaction. If the GET
request fails, the script assigns LR_FAIL to the transaction. On the
Transactions per Second (Failed) graph, the x-axis represents the elapsed
time (in seconds) since the start of the scenario run. The y-axis represents
the number of transactions unsuccessfully performed during the scenario.
lr_start_transaction(wizard);
if (URL("http://www.wizard.com/index.html") == 0)
lr_end_transaction(wizard, LR_PASS);
else {
lr_end_transaction(wizard, LR_FAIL);
lr_log_message("Wizard home page not returned");
}

Testing Tools LoadRunner

# 51 #

For example, the above graph indicates that in the 33rd second of the
scenario, nine insert_row transactions failed. The Failed Transaction report
provides detailed information about the beginning, end, and duration of the
failed, yet completed transaction.

Failed Vuser Report

The Failed Vuser report provides details about all Vusers that were in
the ERROR, ABORTED, or DONE:FAILED states during the scenario execution.
The Ready At and Running At times are relative to the computers system
clock.

Testing Tools LoadRunner

# 52 #

In this scenario, one Vuser failed, two had errors, and three were
aborted.
Scenario Execution Report
The Scenario Execution report details the major events that occurred
during the scenario run. This includes information on every Vuser, such as
when it was ready to run and for how long it ran.

The Ready At and Running At times are based on the computers

system clock.
The Termination Status field indicates the status of the Vuser at the end of
the scenario run (PASSED, FAILED, ERROR, or ABORTED). At the end of the
Group information, there is a summary of the Groups activities.

Testing Tools LoadRunner

# 53 #

Scenario Performance Analysis

After running a scenario, you can create graphs and reports to help you
locate
bottlenecks and analyze overall Vuser performance. You can determine if the
transaction response time was adequate, and how your system handled a
load of many users.
About Scenario Performance
During scenario execution, Vusers generate data as they perform their
transactions. LoadRunner allows you to generate graphs that show scenario
activity or overall scenario performance. Scenario performance graphs and
reports let you analyze Vuser behavior throughout the scenario. The
Performance graphs map the transaction response time, and other general
information about the scenario.
When working with graphs, you can focus on specific segments of the
scenario using the zoom tools. In addition, you can change the granularity of
the graph. When working with reports, you can export the data in ASCII
format or in a custom format for common spreadsheet applications.
Percentile Graph
The Percentile graph analyzes the percentage of transactions that were
performed within a given time range. This graph helps you determine the
percentage of transactions that met the performance criteria defined for
your system. In many instances, you need to determine the percent of
transactions with an acceptable response time. The maximum response time
may be exceptionally long, but if most transactions have acceptable
response times, the overall system is suitable for your needs.

Testing Tools LoadRunner

# 54 #

The x-axis represents the percentage of the total number of transactions

measured during the scenario run. The y-axis represents the time taken to
perform the transactions.
In the above example, a system administrator determines that 2
seconds is an acceptable time for a particular transaction. If 95 percent of
the transactions are 2 seconds or less, the current configuration is suitable. If
more than five percent of the transactions have a response time greater than
fifteen, the configuration must be optimized. In the above graph, 95 percent
of the report transactions were performed in 2 seconds or less.
Compare the Percentile graph to a graph indicating average response
time such as the Transaction Performance Summary graph. A high response
time for several transactions may raise the overall average. However, if the
transactions with a high response time occurred fewer than five percent of
the times, that factor may be insignificant.
Performance Under Load Graph
The Performance Under Load graph indicates transaction times relative
to the number of Vusers running at any given point during the scenario. This
graph helps you view the general impact of Vuser load on performance time
and is most useful when analyzing a scenario with a gradual load. You can
create a gradual load using the scheduling options in the Vuser information
box.

Testing Tools LoadRunner

# 55 #

The x-axis indicates the number of running Vusers, and the y-axis
indicates average transaction time in seconds. In the above graph, the
execution time for the top_sales transaction increases with the number of
running Vusers. For twenty running Vusers, the response time for the
transaction was 3.5 seconds.
Analyzing Scenario Performance
The Performance Under Load Graph indicates transaction times relative
to the number of Vusers running at any given point during the scenario. In
order for this graph to be meaningful, the performance is calculated when
there is a stable load (constant number of running Vusers) for at least five
seconds (by default). If the Vuser load is not stable for at least five seconds,
the transaction time is not calculated and the graph will indicate zero.
For example, a scenario with a load of 50 to 70 Vusers had an average
performance of 10 seconds, but its graph displayed zero. This occurred
because the Vusers did not stabilize for five seconds. You can instruct
LoadRunner to measure transaction time for shorter periods of steady load.
To change the Performance Under Load interval:
Choose Options > Performance Under Load Interval in the Analysis
window.

Testing Tools LoadRunner

# 56 #

 Enter the desired interval.

Click OK to accept the settings.
Regenerate the Performance Under Load graph.
The Performance Under Load report provides the same information as
the graph
for each transaction in table form.

Transaction Performance Graph

The Transaction Performance graph displays the average time taken to
perform
transactions during each second of the scenario run. The x-axis represents
the elapsed time (in seconds) since the start of the scenario run. The y-axis
represents the average time (in seconds) taken to perform each transaction.
You can compare the Transaction Performance graph to the Running Virtual
Users graph to see how the number of running Vusers affects the transaction
performance time.
If you have defined acceptable minimum and maximum transaction
performance
times, you can use this graph to determine whether the performance of the
server is within the acceptable range.

Testing Tools LoadRunner

# 57 #

For instance, the graph above shows the transaction performance

times for two
transactions. You can see that each time the transaction was executed,
performance time decreased. If you compare this graph to the Running
Virtual Users graph, you can see that the performance time improved
because the Vuser load decreased.
Note that the transaction times are only indicated by the peaks in the
graph. When running multiple Vusers, one transaction may begin before the
previous one ends, resulting in a continuous line. The line does not indicate
the actual start and end times of transactions; it is only a mechanism used
by the graph to join the peaks. The Transaction Performance graph may be
displayed using different granularities. The y-axis represents the average
transaction response time within the granularity interval. For example, for a
granularity of 1, the y-axis shows the average response time for each one
second period of the scenario. For a granularity of 2, the y-axis shows the
average response time for every two second period of the scenario. In the
graphs below, the same scenario results are displayed in a granularity of 2,
Testing Tools LoadRunner

# 58 #

5, and 10 (from top to bottom). The lower the granularity, the more detailed
the results. However, it may be useful to view the results with a higher
granularity to study the overall Vuser behavior throughout the scenario. For
example, using a low granularity as in the upper graph, you see the intervals
when no transactions were performed. By viewing the same graph with a
higher granularity, you can easily see that the overall transaction response
time averaged 3.5 seconds.

Transaction Performance Summary Graph and Report

The Transaction Performance Summary graph displays the minimum,
maximum
and average performance time for all the transactions in the scenario.

Testing Tools LoadRunner

# 59 #

The x-axis specifies the name of the transaction. The y-axis shows the
time, rounded off to the nearest second, taken to perform each transaction.
For example, the above graph displays the statistics of the query transaction.
The transaction was performed in a minimum time of 24 seconds, an
average time of 36 seconds, and a maximum time of 42 seconds.
The report shows similar information in table form. The information in
the table is not rounded off to the nearest second, as it is in the graph.

Transaction Performance by Vuser Graph and Report

The Transaction Performance Summary by Vuser graph displays the
time taken by an individual Vuser to perform transactions during the
scenario. The minimum, maximum, and average times are plotted for each
transaction performed by the Vuser. This graph is useful when you have
different types of Vusers in a scenario, and you want to characterize
performance for each type.

Testing Tools LoadRunner

# 60 #

The x-axis specifies the name of the Vuser and the Group to which it
belongs. The y-axis shows the time, in seconds, it takes to perform each
transaction. For example, the above graph displays transaction processing
times for the Vusers in the group15. Vuser two performed the query
transaction in a minimum of 25 seconds, an average of 32 seconds, and a
maximum of 40 seconds.
The Performance Summary by Vuser report shows similar information
for each
Vuser in table format.

Transaction Distribution Graph

The Transaction Distribution graph displays the distribution of the time
taken to
perform a transaction. The transaction response times are divided into five
bars. Each bar shows how many times the transaction was completed within
a given time range. If you compare it to the Transaction Performance
Summary graph, you can see how the average performance was calculated.
Note that this graph only displays information for a single transaction.
Testing Tools LoadRunner

# 61 #

The x-axis represents the time range, in seconds, to perform the

selected transaction. The y-axis represents the number of transactions
executed during the scenario.
For example, the above graph indicates that the performance time for
52 query
transactions was between 38.44 and 41.99 seconds.

Detailed Vuser Report

Testing Tools LoadRunner

# 62 #

The Detailed Vuser report is a list of all transactions executed by each

Vuser during a scenario. The report lists the start and end times, the
duration, and status of each transaction.

The Start time and the End time in this report refer to the system time
at the beginning and end of a transaction. The Result field contains the final
transaction status, either Pass or Fail.

Testing Tools LoadRunner

# 63 #