LoadRunner
LOADRUNNER is a Performance Testing tool that was pioneered by Mercury in 1999. LoadRunner was later acquired by HPE in 2006. In 2016, Loadrunner was acquired by MicroFocus.
LoadRunner supports various development tools, technologies, and communication protocols. In fact, this is the only tool in the market that supports such a large number of protocols to conduct Performance Testing. Performance Test Results produced by Loadrunner are used as a benchmark against other tools.
Why LoadRunner?
LoadRunner is not only pioneer tool in Performance Testing, but it is still a market leader in the Performance Testing paradigm. In a recent assessment, LoadRunner has about 85% market share in Performance Testing industry.
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 a single tool.
LoadRunner Architecture
The architecture of LoadRunner is complex, yet easy to understand.
Suppose you are assigned to check the performance of Amazon.com for 5000 users
In a real-life situation, these all these 5000 users will not be at homepage but in a different section of the websites. How can we simulate differently
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:
- Surfing the Products Page of Amazon.com
- Checkout
- Payment Processing
- Checking MyAccount 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 an analogy from our example controller will add the 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 MyAccount Page ONLY after 500 users have done Payment Processing
Even more complex scenarios are possible
- Initiate 5 VUsers every 2 seconds till a load of 3500 VUsers (surfing Amazon product page) is achieved.
- Iterate for 30 minutes
- Suspend iteration for 25 VUsers
- Re-start 20 VUSers
- Initiate 2 users (in Checkout, Payment Processing, MyAccounts Page) every second.
- 2500 VUsers will be generated at Machine A
- 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.
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.
