Load Runner Tutorial

For QTP Documents visit: www.gcreddy.com

LoadRunner

Understanding The LoadRunner

To load your client/server system, LoadRunner emulates an environment wheremultiple 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 questions—and more—a 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:

Testing Tools – LoadRunner# 1 #


It is expensive, requiring large amounts of both personnel and machinery

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 users—operating 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 Vusers—from 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 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:



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 Vuserscript 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.



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 hosts—machines 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 LoadRunner’s graphs and reports to analyze the server’s 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 bank’s ATMs. 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.

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 generateserver 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:



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.



The operations that a GUI Vuser performs on an application are defined in a GUI Vuser script. You create GUI Vuser scripts using Mercury Interactive’s 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 Interactive’s 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 applications—they access the server using LoadRunner API functions. These API functions emulate the input from an actual application.



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 LoadRunner’s Vuser Script Generator (VuGen) or by using LoadRunner’s 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.



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.



Working with VuGen – Introducing VuGen

About VuGen

The Vuser Script Generator, also known as VuGen, is LoadRunner’s 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 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 theLoadRunner 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 application’s 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.



In addition, when a Vuser communicates directly with a server, system resourcesare 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.



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 JavaVusers. 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.



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.



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 VuGen’s 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



retrieve runtime information about the Vusers participating in the scenario. VuGen helps you generate most of the Vuser functions by recording from your application—other 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 application—such 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 server’s performance per transaction using LoadRunner’s 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.



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 point in the Name box. Click OK to accept the rendezvous name. VuGen inserts an lr_rendezvous statement into the Vuser script. For example, the following function defines a rendezvous point named rendezvous1: lr_rendezvous(“rendezvous1”);



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.



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.



Understanding LoadRunner • The LoadRunner Controller at a GlanceThe 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 MenuYou select LoadRunner commands from the menus on the menu bar.

Some commands use standard Microsoft Windows shortcut conventions.



Choosing Commands from the ToolbarYou 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.



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.



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 aSort 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 list—the list of machines, or hosts, that execute Vuser scripts during a scenario run.



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).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).



By default, LoadRunner stores temporary files on the host during scenario execution in a temporary directory specified by the host’s 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.



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.

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 host—all

the Windows

GUI Vusers running on the specified host will access this file.

To select the location of WinRunner for a GUI Vuser:


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 host’s 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.

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 host—until 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:


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 host’s environment variables (on 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:


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

To develop a scenario, you create a host list, a script list, and a Vuser list. This describes how to create a script list—the 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 script’s 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.



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.

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 script’s 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 list—the list of all the Vusers that can run during scenario execution.

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 server’s 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 server’s 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 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.

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. 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.

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: 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 system’s 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. 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 Vuser’s status changes from DOWN to PENDING to INITIALIZING to READY. If a Vuser fails to initialize, the Vuser status changes to ERROR.

Running Vusers

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 rendezvousbefore the Controller releases them.

To manually release Vusers from a rendezvous:

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.

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.

The Output window also displays:

The time each message arrived The type of message sent The Vuser’s host The ID of the Vuser that sent the message The 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 Vuser’s 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 LoadRunner’s graphs and reports to analyze the performance of your client/server system.

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 headerand a toolbar.

Report HeaderThe header displays general scenario information.

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.

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.

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 Members Released Reason

Query_md 11:54:11 11:55:06 50 40 Time outQuery_md 11:55:11 11:55:42 50 10 by VuserQuery_md 11:55:43 11:56:01 50 50 OKQuery_md 11:56:19 11:57:21 50 48 Time out

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.



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 224th 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 terminated—no 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");}

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 computer’s system clock.

In this scenario, one Vuser failed, two had errors, and three were aborted.

Scenario Execution ReportThe 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 computer’s 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 Group’s activities.

Scenario Performance Analysis

After running a scenario, you can create graphs and reports to help you locatebottlenecks 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.

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.

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.

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 graphfor each transaction in table form.

Transaction Performance Graph

The Transaction Performance graph displays the average time taken to performtransactions 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 performancetimes, you can use this graph to determine whether the performance of the server is within the acceptable range.



For instance, the graph above shows the transaction performance times for twotransactions. 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, 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, maximumand average performance time for all the transactions in the scenario.



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.



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 eachVuser in table format.

Transaction Distribution GraphThe Transaction Distribution graph displays the distribution of the time

taken toperform 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.



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 querytransactions was between 38.44 and 41.99 seconds.

Detailed Vuser Report



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.
