Internal Architecture of LoadRunner tool

Internal Architecture of LR tool

VuGen stores and retrieves a vugen.ini file in the Windows folder. Vu scripts can be coded to use variable values obtained from parameter files external to the script. In the QTWeb.lrp file which is available within the LoadRunner's  dat\protocols folder section [Vugen], add entry MaxThreadPerProcess=5 to limit the number of threads managed by each load generator mdrv.exe process.

Application servers under test are placed under stress by driver processes mdrv.exe (the Multi-threaded Driver Process) and r3vuser.exe which emulate application clients such as Internet Explorer web browser. It performs 3 main actions: cpp (C language pre-processor), cci (C pre-compiling) which creates a file with ci file, and execute using the driver for the protocol technology being tested.

Runs can be invoked to run "silently" by invoking Mdrv.exe from a Windows batch script. Virtual Vusers are invoked as groups (logical collection of virtual users running the same script on a specific load generator machine) by agents (3,900K magentproc.exe) running as a service or as a process on load generator client machines.

Each machine hosting agents maintains an Execution Log in a .qtp file. When logging is enabled, the agent also creates within the results folder a sequential log file for each Vuser (segregated by Vuser group). During execution, this file is displayed in the view > Show Output window on the LoadRunner Controller machine.

Agents are launched by the Remote Agent Dispatcher process (formerly called Remote Command Launcher (RCL)) on each load generator machine. Each agent refer to scenario (.lrs) definition files to determine which Vuser groups and scripts to run on host machines.

The Controller is invoked using parameter values within files in the Windows OS folder (WINNT for Windows 2000 and WINDOWS for Windows XP). The Windows folder is used because LoadRunner is designed to have only one instance of Controller running at a time on a machine. The Controller (wlrun.exe) sends a copy of scenario files along with the request. Upon a pre-set delay, the Scheduler running on a Controller machine instructs agents (via Windows port 54345 or dynamic UNIX port) to initiate test session scenarios.

During a run, execution results are stored to a results folder. Best practice to set Results Settings to "Automatically create a results directory for each scenario execution." which means that LR will increment the name of the Results Name when we start a scenario runs. For example, a value of "Res11" will be automatically incremented to "Res12" or sometimes "Res11-1". Errors are written to the output.mdb MS Access database.

Within each results folder, a "Log" folder is automatically created to contain a log file for each group. After a run, to view a log file from within the Controller, click then right-click on a group to select "Show Vuser Log".  As a scenario is run, monitors maintain counters locally on each host.

After a run, the "collate" process takes .eve and .lrr result files and creates in the results folder a temporary .mdb (MS-Access) database.

The Analysis Module (8,320K analysisu.exe)

It generates analysis graphs and reports using data from the .mdb database. The LoadRunner Results file results_name.lrr from each scenario run -- also called an Analysis document file -- is read by the Analysis program to display Percentile graphs.

By default, the LRReport folder is created in the test analyst's local machine My Documents folder to store Analysis Session files. They can optionally be formatted in HTML. Their format are controlled by a .tem template file.



Diagram of Overview of LR tool internal Architecture