Load Runner

Architecture Overview

LoadRunner works by creating virtual users who take the place of real users operating client software, such as Internet Explorer sending requests using the HTTP protocol to IIS or Apache web servers.

Requests from many virtual user clients are generated by "Load Generators" in order to create a load on various servers under test

These load generator agents are started and stopped by Mercury's "Controller" program.

The Controller controls load test runs based on "Scenarios" invoking compiled "Scripts" and associated "Run-time Settings".

Scripts are crafted using Mercury's "Virtual user script Generator" (named "V U Gen"), It generates C-language script code to be executed by virtual users by capturing network traffic between Internet application clients and servers.

With Java clients, VuGen captures calls by hooking within the client JVM.

During runs, the status of each machine is monitored by the Controller.

At the end of each run, the Controller combines its monitoring logs with logs obtained from load generators, and makes them available to the "Analysis" program, which can then create run result reports and graphs for Microsoft Word, Crystal Reports, or an HTML webpage browser.

Each HTML report page generated by Analysis includes a link to results in a text file which Microsoft Excel can open to perform additional analysis.

Errors during each run are stored in a database which can be read using Microsoft Access

Virtual Users (Vusers)

Unlike a WinRunner workstation which emulates a single user's use of a client, LoadRunner can emulate thousands of Virtual Users.

Load generators are controlled by VuGen scripts which issue non-GUI API calls using the same protocols as the client under test. But WinRunner GUI Vusers emulate keystrokes, mouse clicks, and other User Interface actions on the client being tested Only one GUI user can run from a machine unless LoadRunner Terminal Services Manager manages remote machines with Terminal Server Agent enabled and logged into a Terminal Services Client session.

During run-time, threaded vusers share a common memory pool. So threading supports more Vusers per load generator.

The Status of Vusers on all load generators start from "Running", then go to "Ready" after going through the init section of the script. Vusers are "Finished" in passed or failed end status. Vusers are automatically "Stopped" when the Load Generator is overloaded.

No additional license is needed to monitor standard web (HTTP) servers (Apache, IIS, and Netscape).

To use Web Services Monitors for SOAP and XML, a separate license is needed, and vUsers require the Web Services add-in installed with Feature Pack (FP1)

Controller

Once a script is prepared in Vugen, it is run via the Controller. Each run is called as a scenario with some preset settings. LoadRunner provides for the usage of various machines to act as LoadGenerators. For example, to run a test of 100 users, we can use three or more machines with Loadgenerator installed in them. The tester will then provide the script and the name of the machine which is going to act as a load generator along with the number of users who are going to run from that machine. LoadRunner uses Monitors to monitor the performance of individual components. But each monitor is to be purchased separately from Mercury. Some monitors include Oracle Monitors, WebSphere Monitors, etc... Once a scenario is set and the run is completed, the result of the scenario can be viewed via the Analysis tool


Analysis

This tool takes the completed scenario result and prepares the necessary graphs for the tester to view। Also, graphs can be merged to get a good picture of the performance। The tester can then make needed adjustments to the graph and prepare a LoadRunner report. The report, including all the necessary graphs, can be saved in several formats, including HTML and Microsoft Word format.
LoadRunner Internal Architecture: