LoadRunner_Additional

LOAD RUNNER



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.





LoadRunner 7 Features & Benefits



New Tuning Module Add-In

The LoadRunner Tuning Module allows customers to isolate and resolve system

performance bottlenecks. Once the application has been stress tested using

LoadRunner, the Tuning Module provides component test libraries and a

knowledgebase that help users isolate and resolve performance bottlenecks.



WAN Emulation Support

This powerful feature set enables LoadRunner to quickly point out the effect of the

wide area network (WAN) on application reliability, performance, and response

time. Provided through technology from Shunra Software, this WAN emulation

capability introduces testing for bandwidth limits, latency, network errors, and more

to LoadRunner.



Sun ONE Studio4 IDE Add-in

Mercury Interactive and Sun Microsystems have worked together to integrate

LoadRunner with the Sun ONE Studio4 add-in.



JBuilder for Java IDE Add-in

LoadRunner now works with Borland's JBuilder integrated development environment

(IDE) to create powerful support for J2EE applications. This add-in enables LoadRunner

users who create J2EE applications and services with JBuilder to create virtual users

based on source code within a JBuilder project.



Native ICA Support for Citrix MetaFrame

LoadRunner now supports Citrix's Independent Computing Architecture (ICA) for

the testing of applications being deployed with Citrix MetaFrame. This support is

the first native ICA load testing solution of its kind, jointly developed with Citrix.

Web Transaction Breakdown Monitor for Isolating Performance Problems

Now you can more efficiently isolate performance problems within your architecture.

LoadRunner's Web Transaction Breakdown Monitor splits end-to-end transaction

response times for the client, network, and server and provides powerful drill-down

capabilities.



Data Wizard for Data-Driven Testing

LoadRunner's Data Wizard enables you to quickly create data-driven tests and

eliminate manual data manipulation. It connects directly to back-end database

servers and imports desired data into test scripts.



Goal-Oriented Testing with AutoLoad

The new AutoLoad technology allows you to pre-define your testing objectives beyond

the number of concurrent users to streamline the testing process.

Enterprise Java Bean Testing

By testing EJB components with LoadRunner, you can identify and solve problems

during the early stages of application development. As a result, you can optimize

performance before clients have been developed and thereby save time and resources.



XML Support

With LoadRunner's XML support, you can quickly and easily view and manipulate XML

data within the test scripts

Hosted Virtual Users

How it Work

LoadRunner Hosted Virtual Users complements in-house load testing tools and

allows companies to load test their Web-based applications from outside the

firewall using Mercury Interactive's infrastructure. Customers begin by using

LoadRunner Hosted Virtual Users' simple Web interface to schedule tests and

reserve machines on Mercury Interactive's load farm. At the scheduled time, they

select the recorded scripts to be uploaded and start running the tests on the host

machines*. These scripts will emulate the behavior of real users on the application

and generate load on the system.

Through LoadRunner Hosted Virtual Users’ Web interface, testers can view real-

time performance metrics, such as hits per second, throughput, transaction response

times and hardware resource usage (e.g., CPU and memory levels). They also can

view performance metrics gathered by Mercury Interactive’s server monitors and

correlate this with end-user performance data to diagnose bottlenecks on the back

end.

The interface to LoadRunner Hosted Virtual Users enables test teams to control the

load test and view tests in progress, no matter their locations. When the test is

complete, testers can analyze results online, as well as download data for further

analysis.

*Customers who do not own LoadRunner can download the VUGen component for

free to record their scripts. Likewise, the LoadRunner analysis pack can be

downloaded for free.

LoadRunner Hosted Virtual Users gives testers complete control of the testing

process while providing critical real-time performance information, as well as views

of the individual machines generating the load.



Features and Benefits

Provides pre- and post-deployment testing.

At any time in the application lifecycle, organizations can use LoadRunner Hosted

Virtual Users to verify performance and fine-tune systems for greater efficiency,

scalability and availability. The application under test only needs to be accessible

via the Web.

Complements in-house solutions to provide comprehensive load testing.

By combining LoadRunner Hosted Virtual Users with Mercury Interactive's

LoadRunner or another in-house load testing tool, operations groups can thoroughly

load test their Web applications and Internet infrastructures from inside and outside

the firewall.

Gives customers complete control over all load testing.

Testing groups create the scripts, run the tests and perform their own analyses. They

can perform testing at their convenience and easily access all performance data to

quickly diagnose performance problems.

Provides access to Mercury Interactive's extensive load testing infrastructure.

With LoadRunner Hosted Virtual Users, organizations do not need to invest in

additional hardware, software or bandwidth to increase their testing coverage.

Mercury Interactive’s load testing infrastructure is available 24x7 and consists of

load farms located worldwide. As a result, organizations can generate real-user

loads over the Internet to stress their Web-based applications at any time, from

anywhere.



How the Monitors Work

To minimize the impact of the monitoring on the system under test, LoadRunner

enables IT groups to extract data without having to install intrusive capture agents

on the monitored servers. As a result, LoadRunner can be used to monitor the

performance of the servers regardless of the hardware and operating system on

which they run. Setup and installation of the monitors therefore is trivial. Since all

the monitoring information is sampled at a low frequency (typically 1 to 5 seconds)

there is only a negligible effect on the servers.



Supported Monitors

Astra LoadTest and LoadRunner support monitors for the following components:

Client-side Monitors

End-to-end transaction monitors - Provide end-user response times, hits per second,

transactions per second



Hits per Second and Throughput

Hits per Second

The Hits per Second graph shows the number of hits on the Web server (y-axis) as a

function of the elapsed time in the scenario (x-axis). This graph can display the

whole scenario, or the last 60, 180, 600 or 3600 seconds. You can compare this

graph to the Transaction Response Time graph to see how the number of hits affects

transaction performance.

Throughput

The Throughput graph shows the amount of throughput on the Web server (y-axis)

during each second of the scenario run (x-axis). Throughput is measured in

kilobytes and represents the amount of data that the Vusers received from the server

at any given second. You can compare this graph to the Transaction Response Time

graph to see how the throughput affects transaction performance.

HTTP Responses

HTTP Responses The HTTP Responses per Second graph shows the number of

HTTP status codes, which indicate the status of HTTP requests, for example, “the

request was successful,” “the page was not found” returned from the Web server

during each second of the scenario run (x-axis), grouped by status code.

Load Testing Monitors

Pages Downloaded per Second

 Pages Downloaded per Second The Pages Downloaded per Second graph

shows the number of Web pages downloaded from the server during each

second of the scenario run. This graph helps you evaluate the amount of

load Vusers generate, in terms of the number of pages downloaded. Like

throughput, downloaded pages per second is a representation of the amount

of data that the Vusers received from the server at any given second.



User-defined Data Point

User Defined Data Points graph allows you to add your own measurements by

defining a data point function in your Vuser script. Data point information is

gathered each time the script executes the function or step. The User-Defined Data

Point graph shows the average value of the data points during the scenario run. The

x-axis represents the number of seconds elapsed since the start time of the run. The

y-axis displays the average values of the recorded data point statements.

Transaction Monitors

 Transaction Response Time

The Transaction Response time graph shows the response time of

transactions in seconds (y-axis) as a function of the elapsed time in the

scenario (x-axis).

 Transaction per Second (Passed)

The Transaction per Second (Passed) graph shows the number of successful

transactions performed per second (y-axis) as a function of the elapsed time

in the scenario (x-axis).

 Transaction per Second (Failed)

The Transaction per Second (Failed) graph shows the number of failed

transactions per second (y- axis) as a function of the elapsed time in the

scenario (x- axis).



Virtual User Status

The monitor's Runtime graph provides information about the status of the Vusers

running in the current scenario on all host machines. The graph shows the number

of running Vusers, while the information in the legend indicates the number of

Vusers in each state.

The Status field of each Vuser displays the current status of the Vuser. The

following table describes each Vuser status.

 Running

The total number of Vusers currently running on all load generators.

 Ready

The number of Vusers that completed the initialization section of the script

and are ready to run.

 Finished

The number of Vusers that have finished running. This includes both Vusers

that passed and failed

 Error

The number of Vusers whose execution generated an error.

Web Transaction Breakdown Graphs

 DNS Resolution

Displays the amount of time needed to resolve the DNS name to an IP

address, using the closest DNS server. The DNS Lookup measurement is a

good indicator of problems in DNS resolution, or problems with the DNS

server.

 Connection Time

Displays the amount of time needed to establish an initial connection with

the Web server hosting the specified URL. The connection measurement is a

good indicator of problems along the network. It also indicates whether the

server is responsive to requests.

 Time To First Buffer

Displays the amount of time that passes from the initial HTTP request

(usually GET) until the first buffer is successfully received back from the

Web server. The first buffer measurement is a good indicator of Web server

delay as well as network latency.

 Server and Network time

The Time to First Buffer Breakdown graph also displays each Web page

component's relative server and network time (in seconds) for the period

of time until the first buffer is successfully received back from the Web

server. If the download time for a component is high, you can use this graph

to determine whether the problem is server- or network- related.

 Receive Time

Displays the amount of time that passes until the last byte arrives from the

server and the downloading is complete. The Receive measurement is a

good indicator of network quality (look at the time/size ratio to calculate

receive rate).

 Client Time

Displays the average amount of time that passes while a request is delayed

on the client machine due to browser think time or other client-related

delays.

 Error Time

Displays the average amount of time that passes from the moment an HTTP

request is sent until the moment an error message (HTTP errors only) is

returned

 SSL Handshaking Time

Displays the amount of time taken to establish an SSL connection (includes

the client hello, server hello, client public key transfer, server certificate

transfer, and other stages). The SSL Handshaking measurement is only

applicable for HTTPS communications

 FTP Authentication

Displays the time taken to authenticate the client. With FTP, a server must

authenticate a client before it starts processing the client's commands. The

FTP Authentication measurement is only applicable for FTP protocol

communications.

Server Monitors

NT/UNIX/Linux monitors - Provide hardware, network and operating system

performance metrics, such as CPU, memory and network throughput.



The following list describes the recommended objects to be monitored during a

load test:

ASP Server

Cache

HTTP Content Index

Internet Information Service Global

Logical Disk

Memory

Physical Disk

Processor

Server

Server Work Queues

System

ASP Server

 Debugging Requests - Number of debugging document requests.

 Errors during Script Runtime - Number of requests failed due to runtime

errors.

 Errors from ASP Preprocessor - Number of requests failed due to

preprocessor errors.

 Errors from Script Compilers - Number of requests failed due to script

compilation errors.

 Errors/Sec - The number of errors per second.

 Memory Allocated - The total amount of memory, in bytes, currently

allocated by Active Server Pages

 Request Bytes In Total - The total size, in bytes, of all requests.

 Request Bytes Out Total - The total size, in bytes, of responses sent to

clients. This does not include standard HTTP response headers.

 Request Execution Time - The number of milliseconds required to execute

the most recent request.

 Request Wait Time - The number of milliseconds the most recent request

was waiting in the queue.

 Requests Disconnected - The number of requests disconnected due to

communication failure.

 Requests Executing - The number of requests currently executing.

 Requests Failed Total - The total number of requests failed due to errors,

authorization failure and rejections.

 Requests Not Authorized - The number of requests failed due to insufficient

access rights.

 Requests Succeeded - The number of requests that were executed

successfully.

 Requests Timed Out - The number of requests that timed out.

Cache

 Async Copy Reads/Sec - The frequency of reads from cache pages that

involve a memory copy of the data from the cache to the application's

buffer. The application will regain control immediately, even if the disk

must be accessed to retrieve the page.

 Async Data Maps/Sec - The frequency that an application uses a file system,

such as NTFS or HPFS, to map a page of a file into the cache to read

because it does not wish to wait for the cache to retrieve the page if it is not

in main memory.

 Async Fast Reads/Sec - The frequency of reads from cache pages that

bypass the installed file system and retrieve the data directly from the cache.

Normally, file I/O requests will invoke the appropriate file system to

retrieve data from a file. This path, however, permits direct retrieval of

cache data without file system involvement, as long as the data is in the

cache. Even if the data is not in the cache, one invocation of the file system

is avoided. If the data is not in the cache, the request (application program

call) will not wait until the data has been retrieved from disk, but will get

control immediately.

 Fast Reads/Sec - The frequency of reads from cache pages that bypass the

installed file system and retrieve the data directly from the cache. Normally,

file I/O requests invoke the appropriate file system to retrieve data from a

file. This path, however, permits direct retrieval of cache data without file

system involvement if the data is in the cache. Even if the data is not in the

cache, one invocation of the file system is avoided.

 Lazy Write Flushes/Sec - The frequency with which the cache's Lazy Write

thread has written to disk. Lazy Writing is the process of updating the disk

after the page has been changed in memory. In this way, the application

making the change to the file does not have to wait for the disk write to be

completed before proceeding. More than one page can be transferred on

each write operation.



HTTP Content Index

 %Cached Hits - Percentage of queries found in the query cache.

 %Cache Misses - Percentage of queries not found in the query cache.

 Active Queries - Current number of running queries.

 Cache Items - Number of completed queries in cache.Current Requests

Queued - Current number of query requests queued.

 Queries per Minute - Number of queries per minute.

 Total Queries - Total number of queries run since service start.

 Total Requests Rejected Total number of query requests rejected.

Internet Information Service Global

 Cache Hits % - The ratio of cache hits to all cache requests.

 Cache Misses - The total number of times a file open, directory listing or

service-specific object request was not found in the cache.

 Cached Files Handles - The number of open file handles cached by all of the

Internet Information Services.

 Current Blocked Async I/O Requests - Current requests temporarily blocked

due to bandwidth throttling settings.

 Directory Listings - The number of directory listings cached by all of the

Internet Information Services.

 Measured Async I/O Bandwith Usage - Measured bandwidth of

asynchronous I/O averaged over a minute.

 Objects - The number of objects cached by all of the Internet Information

Services. The objects include file handle tracking objects, directory listing

objects and service specific objects.

 Total Allowed Async I/O Requests - Total requests allowed by bandwidth

throttling settings (counted since service startup).

 Total Blocked Async I/O Requests - Total requests temporarily blocked due

to bandwidth throttling settings (counted since service startup).



Logical Disk

 % Disk Read Time - The percentage of elapsed time that the selected disk

drive was busy servicing read requests.

 % Disk Time - The percentage of elapsed time that the selected disk drive

was busy servicing read or write requests.

 % Disk Write Time - The percentage of elapsed time that the selected disk

drive was busy servicing write requests.

 % Free Space - The ratio of the free space available on the logical disk unit

to the total usable space provided by the selected logical disk drive

 Avg. Disk Bytes/Read - The average number of bytes transferred from the

disk during read operations.

 Avg. Disk Bytes/Transfer - The average number of bytes transferred to or

from the disk during write or read operations.

Memory

 % Committed Bytes in Use - The ratio of the Committed Bytes to the

Commit Limit. This represents the amount of available virtual memory in

use. Note that the Commit Limit may change if the paging file is extended.

This is an instantaneous value, not an average.

 Available Bytes - Displays the size of the virtual memory currently on the

Zeroed, Free and Standby lists. Zeroed and Free memory is ready for use,

with Zeroed memory cleared to zeros. Standby memory is memory removed

from a process's Working Set but still available. Notice that this is an

instantaneous count, not an average over the time interval.

 Cache Bytes - Measures the number of bytes currently in use by the system

cache. The system cache is used to buffer data retrieved from disk or LAN.

In addition, the system cache uses memory not in use by active processes in

the computer.

 Cache Bytes Peak - Measures the maximum number of bytes used by the

system cache. The system cache is used to buffer data retrieved from disk or

LAN. In addition, the system cache uses memory not in use by active

processes in the computer.

 Cache Faults/Sec - Cache faults occur whenever the cache manager does not

find a file's page in the immediate cache and must ask the memory manager

to locate the page elsewhere in memory or on the disk, so that it can be

loaded into the immediate cache.



Physical Disk

 % Disk Read Time - The percentage of elapsed time that the selected disk

drive is busy servicing read requests.

 % Disk Time - The percentage of elapsed time that the selected disk drive is

busy servicing read or write requests.

 % Disk Write Time - The percentage of elapsed time that the selected disk

drive is busy servicing write requests.

 Avg. Disk Bytes/Read - The average number of bytes transferred from the

disk during read operations.

 Avg. Disk Bytes/Transfer - The average number of bytes transferred to or

from the disk during write or read operations.

 Avg. Disk Bytes/Write - The average number of bytes transferred to the disk

during write operations.

 Avg. Disk Queue Length - The average number of both read and write

requests that were queued for the selected disk during the sample interval.

Processor

 % DPC Time - The percentage of elapsed time that the Processor spent in

Deferred Procedure Calls (DPC). When a hardware device interrupts the

Processor, the Interrupt Handler may elect to execute the majority of its

work in a DPC. DPCs run at lower priority than Interrupts. This counter can

help determine the source of excessive time being spent in Privileged Mode.

 % Interrupt Time - The percentage of elapsed time that the Processor spent

handling hardware Interrupts. When a hardware device interrupts the

Processor, the Interrupt Handler will execute to handle the condition,

usually by signaling I/O completion and possibly issuing another pending

I/O request. Some of this work may be done in a DPC (see % DPC Time.)

 % Privileged Time - The percentage of processor time spent in Privileged

Mode in non-idle threads. The Windows NT service layer, the Executive

routines, and the Windows NT Kernel execute in Privileged Mode. Device

drivers for most devices other than graphics adapters and printers also

execute in Privileged Mode. Unlike some early operating systems,

 % Processor Time - Processor Time is expressed as a percentage of the

elapsed time that a processor is busy executing a non-idle thread. It can be

viewed as the fraction of the time spent doing useful work. Each processor

is assigned an idle thread in the idle process that consumes those

unproductive processor cycles not used by any other threads.

 % User Time - The percentage of processor time spent in User Mode in non-

idle threads. All application code and subsystem code execute in User

Mode. The graphics engine, graphics device drivers, printer device drivers

and the window manager also execute in User Mode. Code executing in

User Mode cannot damage the integrity of the Windows NT Executive,

Kernel, and device drivers. Unlike some early operating systems, Windows

NT uses process boundaries for subsystem protection in addition to the

traditional protection of User and Privileged modes.

Server

 Blocking Requests Rejected - The number of times the server has rejected

blocking Server Message Blocks (SMBs) due to insufficient count of free

work items. May indicate whether the maxworkitem or minfreeworkitems

server parameters need tuning.

 Bytes Received/Sec - The number of bytes the server has received from the

network. This value indicates how busy the server is.

 Bytes Total/Sec - The number of bytes the server has sent to and received

from the network. This value provides an overall indication of how busy the

server is.

 Bytes Transmitted/Sec - The number of bytes the server has sent on the

network. This value indicates how busy the server is.

 Context Blocks Queued/Sec - - The rate that work context blocks had to be

placed on the server's FSP queue to await server action.

 Errors Access Permissions - The number of times file opens on behalf of

clients have failed with STATUS_ACCESS_DENIED. Can indicate

whether somebody is randomly attempting to access files in hopes of

accessing data that was not properly protected.

NAVIGATIONAL STEPS FOR LOADRUNNER LAB-EXERCISES



1.Creating Script Using Virtual User Generator

 Start-> program Files->Load Runner->Virtual User Generator

 Choose File->New

 Select type and Click Ok Button

 Start recording Dialog Box appears

 Besides Program to Record, Click Browser Button and Browse for

the Application

 Choose the Working Dir

 Let start recording into sections Vuser_Init and click Ok button

 After the application appears, change sections to Actions.

 Do some actions on the application

 Change sections to Vuser_End and close the application

 Click on stop Recording Icon in the tool bar of Vuser Generator

 Insert the Start_Transaction and End_Transactions.

 Insert the Rendezvous Point

 Choose :Vuser->Run, Verify the status of script at the bottom in

Execution Log.

 Choose:File->Save.(Remember the path of the script).

2.Running the script in the Controller with Wizard

 Start-> program Files->Load Runner->Controller.

 Choose: wizard option and click OK.

 Click Next in the welcome Screen

 In the host list , click add button and mention the machine name

Click Next Button

 Select the related script you are generated in Vuser Generator(GUI Vuser

Script,DB script,RTE script)

 Select Simulation group list, cilck edit button and change the group name

,No of Vuser.

 Click Next Button

 Select Finish Button.

 Choose: Group->Init or Group->Run or Scenario->Start.

 Finally Load runner Analysis graph report appears.

3.Running the script in the Controller with out Wizard

 Start-> program Files->Load Runner->Controller.

 Choose File->New, Four Windows appears

 Select Vusers window.

 Select Group->Add Group

 Vuser Information Box appears

 Select Group Name, Vuser Quantity, Host Name.

 Select Script and select Add button, select path of the script.

 Click OK button.

 Choose: Group->Init or Group->Run or Scenario->Start.

 Select Results->Analyse Results.

4.Creating GUI Vuser Script Using Winrunner(GUI Vuser)

 Start-> Program Files->Winrunner->Winrunner.

 Chose: File->New

 Start recording through

Create->Record ContextSensitive Mode

 Invoke the application

 Do some actions on the application.

 Select Stop Recording

Create->Stop Record

 Declare the Transactions and Rendezvous Point at the top of script

Declare_transaction(“ “);

Declare_rendezvous(“”);

 Identify where the transaction points to be inserted.

Start_transaction(“”);

End_transaction(“”);

 Insert the Rendezvous Point

Rendezvous(“”);

 Save the script and remember the path of the script.

5.Running the script in the Controller with Wizard

 Start-> program Files->Load Runner->Controller.

 Choose: wizard option and click OK.

 Click Next in the welcome Screen

 In the host list , click add button and mention the machine name

Click Next Button

 In GUI Vuser Script, click add button and mention the name of Script

 Click Next button.

 Select Simulation group list, cilck edit button and change the group

name ,No of Vuser.

 Click Next Button

 Select Finish Button.

 Select Vuser window, select tools->option

Select winrunner tab,set the path of Winrunner



Path:Program files->winrunner->dat->wrun.ini

 Select Host window, select Host->details

Select Vuser Limits tab, select GUI-winrunner check box.

Select winrunner tab , set path

Path:Program files->winrunner->dat->wrun.ini

 Choose: Group->Init or Group->Run or Scenario->Start.

 Finally Load runner Analysis graph report appears.