Introduction of LoadRunner

LoadRunner is an industry-leading performance and load testing product by Hewlett-Packard (since it acquired Mercury Interactive in November 2006) for examining system behavior and performance, while generating actual load.

LoadRunner can emulate hundreds or thousands of concurrent users to put the application through the rigors of real-life user loads, while collecting information from key infrastructure components (Web servers, database servers etc). The results can then be analysed in detail, to explore the reasons for particular behaviour.

Consider the client-side application for an automated teller machine (ATM). Although each client is connected to a server, in total there may be hundreds of ATMs open to the public. There may be some peak times — such as 10 a.m. Monday, the start of the work week — during which the load is much higher than normal. In order to test such situations, it is not practical to have a testbed of hundreds of ATMs. So, given an ATM simulator and a computer system with LoadRunner, one can simulate a large number of users accessing the server simultaneously. Once activities have been defined, they are repeatable. After debugging a problem in the application, managers can check whether the problem persists by reproducing the same situation, with the same type of user interaction. 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

Load Runner is divided up into 3 smaller applications:

The Virtual User Generator allows us to determine what actions we would like our Vusers, or virtual users, to perform within the application. We create scripts that generate a series of actions, such as logging on, navigating through the application, and exiting the program.

The Controller takes the scripts that we have made and runs them through a schedule that we set up. We tell the Controller how many Vusers to activate, when to activate them, and how to group the Vusers and keep track of them.

The Results and Analysis program gives us all the results of the load test in various forms. It allows us to see summaries of data, as well as the details of the load test for pinpointing problems or bottlenecks.

Introduction of the LoadRunner Solution

• 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 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 often as you
need.

How to use 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

Introduction of LoadRunner Vuser Technology

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.

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 Types

LoadRunner has various types of Vusers. Each type is designed to handle different aspects of today’s client/server architectures. You can use the Vuser types in any combination in a scenario in order to create a comprehensive client/server test.

The following Vuser types are available:

• GUI (Windows and UNIX)

• RTE (Windows and UNIX)

• Database *(CtLib, DbLib, Informix, Oracle, and ODBC)

• Web*

• TUXEDO*

• APPC*

• Windows Sockets*

• Baan

• Java

• DCOM

• PeopleSoft

Working with LoadRunner

Suppose you want to test a bank server that serves many automatic teller machines (ATMs).

The ATMs provide a full range of banking services to the bank’s customers–such as withdrawing and depositing cash. To test the bank server using LoadRunner, you create a scenario. The scenario defines the actions that are performed on the server during the load test. During the scenario that loads and monitors the bank server, you want to:

• emulate conditions of controlled load on the server

• emulate conditions of maximum load on the server

• measure server performance under load

• check where performance delays occur: network or client delays, CPU performance, I/O
delays, database locking, or other issues at the server monitor the network and server
resources under load

Points to note with web_url and web_link:

• web_url is not a context sensitive function while web_link is a context sensitive function. Context
sensitive functions describe your actions in terms of GUI objects (such as windows, lists, and
buttons). Check HTML vs URL recording mode.

• If web_url statement occurs before a context sensitive statement like web_link, it should hit the
server, otherwise your script will get error’ed out.

• While recording, if you switch between the actions, the first statement recorded in a given action
will never be a context sensitive statement.

• The first argument of a web_link, web_url, web_image or in general web_* does not affect the
script replay. For example: if your web_link statements were recorded as web_link(”Hi There”,

“Text=Hello, ABC”,

LAST);

Now, when you parameterize/correlate the first argument to
web_link(”{Welcome to LearnLoadRunner}”,

“Text=Hello, ABC”,

LAST);

On executing the above script you won’t find the actual text of the parameter {Welcome to Learn LoadRunner} instead you will find {Welcome to Learn LoadRunner} itself in the execution log. However to show the correlated/parameterized data you can use lr_eval_string to evaluate the parameter.