Load Runner - Seminar Report

ABSTRACT

Load Runner is a Mercury Interactive Tool that predicts performance and behaviour of the system.By creating lots of load, you can see how the system reacts at peak levels or with simultaneous Users.To test the application and Load Runner emulates an environment where multiple users work concurrently. While the application is under load, Load Runner accurately measures and analyzes the system performance, and its functionality.

Load Runner is a performance and load testing product by Hewlett-Packard  for examining system behavior and performance, while generating actual load. Load Runner 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. The results can then be analyzed in detail, to explore the reasons for particular behaviors. Load testing is to test that if the application works fine with the loads that result from large number of simultaneous users, transactions. Timing for both read and update transactions should be gathered to determine whether system functions are being performed in an acceptable timeframe. This should be done standalone and then in a multi user environment to determine the effect of multiple transactions.

INTRODUCTION:-

Load Runner is a 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. Load Runner 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 analyzed in detail, to explore the reasons for particular behaviors.

• Load Runner is a Mercury Interactive Tool that predicts performance and behaviour of the system.
• By creating lots of load, you can see how the system reacts at peak levels or with simultaneous Users.
• To test the application, Load Runner emulates an environment where multiple users work concurrently. While the application is under load, Load Runner accurately measures and analyzes the system performance, and its functionality.

HP automated load tools.

Simulates load on an application and collects data using monitors.

Has 3 parts

–VuGen

–Controller

 –Analysis

Tests an application under the anticipated usage volume for the environment. Used to determine whether a file meets an SLA under standard usage conditions. Uses a few machine to simulate a large volume of load. Only multi user/distributed applications can be load tested. Load testing is NOT a substitute for functional testing. Load testing is NOT Stress testing. Load testing is to test that if the application works fine with the loads that result from large number of simultaneous users, transactions and to determine whether it can handle peak usage periods. It depends upon through put i.e.

         

Throughput=N*T*D

         N=no of concurrent user

         T=time taken to load data

         D=data load per each transaction

Timing for both read and update transactions should be gathered to         determine whether system functions are being performed in an acceptable timeframe. This should be done standalone and then in a multi user environment to determine the effect of multiple transactions on the timing of a single transaction, to test the performance of the application in different load condition. Load is increased to break points after that it fails. How much load it is tolerate. We consider that as the data integrity affected, data transaction lost, as the server shut down, system shut down.

Manual testing: 

  1) It is time consuming.

   2) It is expensive.

   3) It is very difficult to co-ordinate multiple user.

   4) It is very complicated. 

Automation testing: 

   1) It is time saving.

   2) It is not expensive.

  3) LR CONTROLLER controls the entire v user from a single point. 

  4) It is not complicated.

Load Runner is an automated load testing tool that allows you to test your application before, during and after deployment. This course is designed to give you a firm foundation in basic load testing tasks. The following components of Load Runner – LR Controller and LR Analysis are used to plan for an effective load test. You will create and run load test scenarios using the LR Controller. The LR Analysis component is used to analyze load test results. You will learn to interpret Load Runner analysis graphs and achieve your load testing goals. All topics are support by hands-on labs designed to provide you with the knowledge necessary to load test your system using load runner. We perform load testing once we are done with interface (GUI) testing. Modern system architectures are large and complex. Whereas single user testing primarily on functionality and user interface of a system component, application testing focuses on performance and reliability of an entire system. For example, a typical application-testing scenario might depict 1000 users logging in simultaneously to a system. This gives rise to issues such as what is the response time of the system, does it crash, will it go with different software applications and platforms, can it hold so many hundreds and thousands of users, etc. This is when we set do load and performance testing.  The components of Load Runner are The Virtual User Generator, Controller, and the Agent process, Load Runner Analysis and Monitoring, Load Runner Books Online. We 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 web-based applications, VuGen monitors the client end of the database and traces all the requests sent to, and received from, the database server. We use VuGen to: Monitor the communication between the application and the server; Generate the required function calls; and Insert the generated function calls into a Vuser script.  The Virtual User Generator (VuGen) component is used to record a script. It enables you to develop Vuser scripts for a variety of application types and communication protocols. The Virtual User Generator (VuGen) records the activity between client & server.

Allows users to create scripts on how to interact with the application

Script is recorded based on the protocol of the application it supports-

Is used to create scripts based on how the application will be used be used-

VUGen only used for test creation and not test execution.

Process

–Identify AUT/protocol(s)

–Identify scenarios

–Record script (for each scenario)

–Edit script (as necessary)

Is used to execute Load Runner scripts

Mirrors how multiple users will use the application.

Process

–Identify how many VUsersrun each scenario

–Identify the order/concurrency for each scenario

–Create the controller script

–Execute the controller script

Collects a large amount of information (using monitors) from each server involved in the tests

Provides tools to compare information gathered during each execution.

–Gather statistics for each test execution

–Correlate the statistics

SUPPORTING ENVIRONMENTS:-

Application Deployment Solution - The Citrix protocol. 

Client/Server - MS SQL, ODBC, Oracle Web Applications 11i, DB2 CLI, Sybase Club, Sybase Dublin, Windows Sockets, and DNS protocols.

Custom - C templates, Visual Basic templates, Java templates, JavaScript and VBScript type scripts.

Distributed Components - COM/DCOM, Corba-Java, and Rim-Java protocols. 

 E-Business - FTP, LDAP, Palm, Web (HTTP/HTML), Web Services, and the dual Web/Win socket protocols. 

Enterprise Java Beans -EJB Testing and RMI-Java protocols. 

ERP/CRM - Baan, Oracle NCA, PeopleSoft 8, PeopleSoft-Tuxedo, SAP-Web, SAPGUI, SAPGUI/SAP-Web dual, and Siebel (Siebel-DB2 CLI, Siebel-MSSQL, Siebel-Web, and Siebel-Oracle) protocols.

Legacy

Terminal Emulation (RTE). 

Mailing Services

Internet Messaging (IMAP), MS Exchange (MAPI), POP3, and SMTP.

Streaming

Media Player and RealPlayer protocols. 

Wireless

I-Mode, Voice XML, & WAP protocols. 

Platforms

NT, 2000, XP , Sun, HP, IBM, Linux

VuGen (Virtual User Generator) – records Vuser Scripts that emulate the steps of real Users using the application.

The Controller is an administrative centre for creating, maintaining, and executing scenarios. Starts and stops load tests, and perform other Administrative tasks.

LR Analysis uses the load test results to create graphs and reports that are used to correlate system information and identify both bottlenecks and performance issues.

Tuning helps you quickly isolate and resolve performance bottlenecks. By adding a centralized tuning console to LoadRunner, the Mercury Tuning Module ensures that performance bottlenecks are resolved during testing, and helps you determine the optimized configuration settings for production.

The Load Runner Solution:-

Virtual user Generator- Creates Scripts as one Single User.

Load runner controller- Generate load & collects test results.

Load Runner Terminology

Scenarios

Using Load Runner, you divide your application performance testing requirements into scenarios.

A scenario defines the events that occur during each testing sessions.

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. 

Vusers 

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

A scenario can contain tens, hundreds, or even thousands of Vusers.

Vuser Scripts

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. Vuser scripts include functions that measure and record the performance of the server during the scenario. 

Transactions

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. 

Rendezvous Points

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. 

Controller

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. 

Hosts

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. 

Performance Analysis

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. 

Load Runner Expert Workflow

Plan Load Test:

Identify Business Critical Scenarios. Scenario means a manual work flow. Ex: Login à Open an Account à Logout.

Estimate User Load

    Performance testing requirements will give an idea of users load or the number of users using the product. This will determine the load to be used against the product in testing.

Work Load:

    Ex: 100 users running together. Of this 60 users book a Browse a website. 30 users search a product and 10 users buy the Product.

What is Virtual User (Vuser)?

Virtual users or Vusers emulate the steps of real users. The steps that Vusers perform are recorded in a Vuser Script.

VuGen records Vuser Scripts that emulate the steps of real users using the application

VuGen not only records Vuser scripts, but also runs them. Running scripts from VuGen is useful for debugging 

VuGen records sessions on Windows platforms only. However, a recorded Vuser script can run on both Windows and UNIX platform. 

Process of Recording Script

• Record a basic script
• Enhance the basic script by adding the control-flow statements and other Mercury API functions into the Script
• Configure the Run-time settings
• Verify that the script runs correctly, run it in stand-alone mode
• Integrate into your test: a LoadRunner scenario, Performance Centre load test, Tuning module session, Business process monitor profile.

Virtual User Generator:-

What we can do?

Set up recording options

Record the scripts

Add Comments

Insert Start and End Transactions

Perform Correlation

Add Checks

Add C programming Statements wherever required.

Insert Load Runner Functions if required.

Do Parameterization.

Add Rendezvous Point

Create multiple actions if required. 

Ending and Saving a Recording Session

To complete the recording: 

After you record a typical business process, you complete the recording session by performing the closing steps of your business process and saving the Vuser script. 

Switch to the vuser end section in the floating toolbar, and perform the log off or cleanup procedure. 

Click the stop recording button on the recording Tool Bar

Types of Scenarios

Manual Scenario

Manage your Load Test by specifying the number of Virtual users to run

Goal-Oriented Scenario

Allow LoadRunner Controller to create a Scenario based on the goals you specify.

Manual Scenario

You control the number of Running Vusers at the time which they run.

You can specify how many Vusers run simultaneously

Allows you to run the Vuser in Percentage mode.

LoadRunner Analysis:-

• Analysis provides graphs and reports to help you analyze the performance of your system. These graphs and reports summarize the scenario execution.
• Using these graphs and reports, you can easily pinpoint and identify the bottlenecks in your Application.
• To view a summary of the results after test execution, you can use one or more of the following tools:
• Vuser log files contain a full trace of the scenario run for each Vuser. These files are located in the scenario results directory.
• Controller Output window displays information about the scenario run.
• Analysis graphs help you determine system performance and provide information about transactions and Vusers.
• Graph Data and Raw Data views display the actual data used to generate the graph in a spreadsheet format.
• Report utilities enable you to view a Summary HTML report for each graph or a variety of Performance and Activity reports. You can create a report as a Microsoft Word document, which automatically summarizes and displays the test’s significant data in graphical and tabular format.

Creating Analysis Session

When you run a scenario, data is stored in a result file with an .lrr extension. Analysis is the utility that processes the gathered result information and generates graphs and reports.

When you work with the Analysis utility, you work within a session. An Analysis session contains at least one set of scenario results (lrr file). Analysis stores the display information and layout settings for the active graphs in a file with an .lra extension.

Methods of opening LoadRunner Analysis

Open Analysis directly from the controller (Results > Analyze Results)‏

Start > Programs > Mercury LoadRunner > Applications > Analysis

Start > Programs > Mercury LoadRunner > LoadRunner, selects the Load Testing or Tuning tab, and then clicks Analyze Load Tests or Analyze Tuning Sessions.

You can also instruct controller to open analysis automatically after the Scenario execution by selecting Results > Auto Analysis.

Collating Execution Results

When you run a scenario, by default all Vuser information is stored locally on each Vuser host

After scenario execution the results are automatically collated or consolidated – results from all the hosts are transfer to results directory

You disable automatic collation by choosing Results > Auto collate Results from the controller window

You can collate manually by selecting Results > Collate Results

If your results are not collated Analysis will automatically collate the results before generating the analysis data.

Data Aggregation

Analysis Graphs:-

Analysis graphs are divided into the following categories.

Vuser Graphs - Provide information about Vuser states and other Vuser statistics.

Error Graphs - Provide information about the errors that occurred during the scenario.

Transaction Graphs - Provide information about transaction performance and response time.

Web Resource Graphs - Provide information about the throughput, hits per second, HTTP responses per second, number of retries per second, and downloaded pages per second for Web Vusers.

Web Page Breakdown Graphs - Provide information about the size and download time of each Web page component.

User-Defined Data Point Graphs - Provide information about the custom data points that were gathered by the online monitor.

System Resource Graphs - Provide statistics relating to the system resources that were monitored during the scenario using the online monitor. 

Network Monitor Graphs - Provide information about the network delays. 

Firewall Server Monitor Graphs - Provide information about firewall server resource usage. 

Web Server Resource Graphs - Provide information about the resource usage for the Apache, iPlanet/Netscape, iPlanet (SNMP), and MS IIS Web servers. 

Web Application Server Resource Graphs - Provide information about the resource usage for various Web application servers.

Database Server Resource Graphs - Provide information about database resources. 

Streaming Media Graphs - Provide information about resource usage of streaming media. 

ERP/CRM Server Resource Graphs - Provide information about ERP/CRM server resource usage. 

Java Performance Graphs - Provide information about resource usage of Java-based applications. 

Application Component Graphs - Provide information about resource usage of the Microsoft COM+ server and the Microsoft NET CLR server. 

Application Deployment Solutions Graphs - Provide information about resource usage of the Citrix Meta Frame.

Middleware Performance Graphs - Provide information about resource usage of the Tuxedo and IBM Web Sphere MQ servers.

Security Graphs - Provide information about simulated attacks on the server using the Distributed Denial of Service graph.

Application Traffic Management Graphs - Provide information about resource usage of the F5 BIG-IP server. 

Infrastructure Resources Graphs - Provide information about resource usage of FTP, POP3, SMTP, IMAP, and DNS Vusers on the network client. 

Siebel Diagnostics Graphs - Provide detailed breakdown diagnostics for transactions generated on Siebel Web, Siebel App, and Siebel Database servers. 

Siebel DB Diagnostics Graphs - Provide detailed breakdown diagnostics for SQLs generated by transactions on the Siebel system.

Oracle Diagnostics Graphs - Provide detailed breakdown diagnostics for SQLs generated by transactions on the Oracle NCA system. 

J2EE Diagnostics Graphs - Provide information to trace, time, and troubleshoot individual transactions through J2EE Web, application, and database servers.

PERFORMANCE DETAILS:-

• Web Server Metrics
• SQL Server Metrics 
• Throughput versus user load 
• Response time versus user load 
• Resource utilization versus user load.

Best Practices for Performance Testing  

• Do not allow the test system resources to cross resource threshold limits by a significant margin during load testing, because this distorts the data in your results. 
• Do not run tests in live production environments that have other network traffic. Use an isolated test environment that is representative of the actual production environment. 
• Do not try to break the system during a load test. The intent of the load test is not to break the system. The intent is to observe performance under expected usage conditions. You can stress test to determine the most likely modes of failure so they can be addressed or mitigated. 
• Do not place too much stress on the client test computers. 
• Clear the application and database logs after each performance test run. Excessively large log files may artificially skew the performance results. 
• Identify the correct server software and hardware to mirror your production environment. 
• Use a single graphical user interface (GUI) client to capture end-user response time while a load is generated on the system. You may need to generate load by using different client computers, but to make sense of client-side data, such as response time or requests per second, you should consolidate data at a single client and generate results based on the average values. 
• Include a buffer time between the incremental increases of users during a load test. 
• Use different data parameters for each simulated user to create a more realistic load simulation. 
• Monitor all computers involved in the test, including the client that generates the load. This is important because you should not overly stress the client. 
• Prioritize your scenarios according to critical functionality and high-volume transactions. 
• Use a zero think time if you need to fire concurrent requests, this can help you identify bottleneck issues. 

Stress test critical components of the system to assess their independent

Thresholds.

CONCLUSION:-

Manual testing is so complicated & time consuming, is very difficult to test the application against multiple users. So Load Runner is an automated testing tool to test the application to check the transaction rates, performance behaviors & throughput in a very short time.