Introduction to Load Runner

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

Load Runner supports various development tools, technologies and communication protocols. In fact this is the only tool in market which supports such large number of protocols to conduct performance testing.

Broadly, LoadRunner supports RIA (Rich Internet Applications), Web 2.0 (HTTP/HTML, Ajax, Flex and Silverlight etc.),Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail and above all, Windows Socket. There is no competitor tool in the market which could offer such wide variety of protocols vested in single tool.

What is more convincing to pick LoadRunner for performance testing is the credibility of this tool. LoadRunner has long established reputation as often you will find clients cross verifying your performance benchmarks using LoadRunner. You’ll find relief if you're already using LoadRunner for your performance testing needs.

LoadRunner is tightly integrated with other HP Tools like Unified Functional Test (QTP) & ALM (Application Lifecycle Management) with empowers you to perform your end to end Testing Processes. 

LoadRunner works on a principal of simulating Virtual Users on the subject application. These Virtual Users, also termed as VUsers, replicate client's requests and expect corresponding response to pass a transaction.

Why do you need Performance Testing?

An estimated loss of 4.4 billion in revenue is recorded annually due to poor web performance.

In today's age of Web 2.0, users click away if a website doesn't respond within 8 seconds. Imagine yourself waiting for 5 seconds when searching over Google or making a friend request on Facebook. The repercussions of performance downtime are often more devastating than ever imagined. We've examples such as those that recently hit Bank of America Online Banking, Amazon Web Services, Intuit or Blackberry.

According to Dunn & Bradstreet, 59% of Fortune 500 companies experience an estimated 1.6 hours of downtime every week. Considering the average Fortune 500 Company with a minimum of 10,000 employees is paying $56 per hour, the labor part of downtime costs for such an organization would be $896,000 weekly, translating into more than $46 million per year.

Only a 5 minute downtime of Google.com (19-Aug-13) is estimated to cost the search giant as much as $545,000.

Its estimate that companies lost sales worth $1100 per second due to a recent Amazon Web Service Outage.

When a software system is deployed by an organization, it may encounter many scenarios that possibly result in performance latency. A number of factors cause decelerating performance, few example may include:

·         Increased number of records present in the database

·         Increased number of simultaneous requests made to the system

·         larger number of users accessing the system at a time as compared to the past

What is LoadRunner Architecture?

Broadly speaking, the architecture of LoadRunner is complex, yet easy to understand.

Suppose you are assigned to check performance of Amazon.com for 5000 users

   In a real life situation, these all these 5000 users will not be at homepage but in different section of the websites. How can we simulate different 

VUGen:

VUGen or Virtual User Generator is an IDE (Integrated Development Environment) or a rich coding editor. VUGen is used to replicate System Under Load (SUL) behavior. VUGen provides a "recording" feature which records communication to and from client and Server in form of a coded script - also called VUser script.

So considering the above example, VUGen can record to simulate following business processes:

1.     Surfing the Products Page of Amazon.com

2.     Checkout

3.     Payment Processing

4.     Checking My Account Page

Controller:

Once a VUser script is finalized, Controller is the main component which controls the Load simulation by managing, for example:

·         How many VUsers to simulate against each business process or VUser Group

·         Behavior of VUsers (ramp up, ramp down, simultaneous or concurrent nature etc.)

·         Nature of Load scenario e.g. Real Life or Goal Oriented or verifying SLA

·         Which injectors to use, how many VUsers against each injector

·         Collate results periodically

·         IP Spoofing

·         Error reporting

·         Transaction reporting etc.

Taking analogy from our example controller will add following parameter to the VUGen Script

1) 3500 Users are Surfing the Products Page of Amazon.com

2) 750 Users are in Checkout

3) 500 Users are performing Payment Processing

4) 250 Users are  Checking My Account Page ONLY after 500 users have done Payment Processing

Even more complex scenarios are possible

1.     Initiate 5 VUsers every 2 seconds till a load of 3500 VUsers (surfing Amazon product page) is achieved.

2.     Iterate for 30 minutes

3.     Suspend iteration for 25 VUsers

4.     Re-start 20 VUsers

5.     Initiate 2 users (in Checkout, Payment Processing , My Accounts Page) every second.

6.     2500 VUsers will be generated at Machine A

7.     2500 VUsers will be generated at Machine B

Agents Machine/Load Generators/Injectors

LoadRunner Controller is responsible to simulate thousands of VUsers - these VUsers consume hardware resources for example processor and memory - hence putting a limit on the machine which is simulating them. Besides, Controller simulates these VUsers from the same machine (where Controller resides) & hence the results may not be precise. To address this concern, all VUsers are spread across various machines, called Load Generators or Load Injectors.

As a general practice, Controller resides on a different machine and load is simulated from other machines. Depending upon the protocol of VUser scripts and machine specifications, a number of Load Injectors may be required for full simulation. For example, VUsers for an HTTP script will require 2-4MB per VUser for simulation, hence 4 machines with 4 GB RAM each will be required to simulate a load of 10,000 VUsers.

Taking Analogy from our Amazon Example, the output of this component will be

Analysis:

Once Load scenarios have been executed, the role of "Analysis" component comes in.

During the execution, Controller creates a dump of results in raw form & contains information like, which version of LoadRunner created this results dump and what were configurations.

All the errors and exceptions are logged in a Microsoft access database, named, output.mdb. The "Analysis" component reads this database file to perform various types of analysis and generates graphs.

These graphs show various trends to understand the reasoning behind errors and failure under load; thus help figuring whether optimization is required in SUL, Server (e.g. JBoss, Oracle) or infrastructure.

Below is an example where bandwidth could be creating bottleneck. Let's say Web server has 1GBps capacity whereas the data traffic exceeds this capacity causing subsequent users to suffer. To determine system caters to such needs, Performance Engineer needs to analyze application behavior with abnormal load. Below is a graph LoadRunner generates to elicit bandwidth.

File Extensions: 

VuGen : .Usr is the File Extension

Controller : .lrs is the file Extension ==> .lrr 

Analysis : .lra is the File Extension