Friday, July 18, 2008

LoadRunner Internal Architecture

LoadRunner Internal Architecture
This Visio 2002 file is based on LR8.0





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 brower. It performs 3 main actions:
Kli> cpp (C language pre-processor)
cci (C pre-compiling) which creaes 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.

Mdrv can automatically stop loading Vusers because they communicate with Vusers and monitor CPU usage on Windows Load Generator machines.

A separate JVM is instantiated by each Java-based Vuser on Windows-based machines. Java Vusers are not supported on Unix platforms.


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.


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. The Controller (wlrun.exe) sends a copy of scenario files along with the request.
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.

This means the Controller can be started from a DOS batch (.bat) file (preferrably with a short name on a root drive):

REM Start Controller:
SET M_ROOT=C:\Program Files\Mercury Interactive\LoadRunner\bin
cd %M_ROOT%
wlrun.exe -TestPath D:\Dev\Dev1.lrs -port 8080 -Run -DontClose
pause Press Ctrl-Z to keep this window or


Including the -Run parameter is the same as manually pressing the "Start Scenario" automatically upon invocation. This is not a good idea because you may have to decide about collating the file from a previous run or want to change the output folder.
This assumes that the system's environment PATH variable was updated to include where LoadRunner is installed.





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.

To quickly switch among several applications, save a copy of LoadRunner's ini files after working on it within the Controller, then use Notepad to craft a batch file to copy application-specific versions of ini files before executing wlrun. An example of file copy actions for application XXX:


copy %LRDir%/config/wlrun7-XXX.ini %LRDir%/wlrun7.ini
copy %LRDir%/config/wlrun7-XXX.dft %LRDir%/wlrun7.dft

Prior to v9.0:


copy %WinDir%/wlrun7-XXX.ini %WinDir%/wlrun7.ini
copy %WinDir%/wlrun7-XXX.dft %WinDir%/wlrun7.dft

Some defaults you might want to change:

In the wlrun7.ini file file [output] section, MaxNumberOfOutputMessages= from 10000 to 100000 for long runs. This limits the number of output messages stored in the database.
MaxOutputUIRowsToShow limits the amount of messages/errors (lines) displayed in the Controller's Output window.
In the QTWeb.lrp file within the LoadRunner Program Files dat\protocols folder section [Vugen], add entry MaxThreadPerProcess=5 to limit the number of threads managed by each load generator mdrv.exe process.

Values for DefaultScenarioDir, DefaultScriptDir, DefaultResultDir, and [Recent File List] stored in the wlrun5.ini and wlrun7.dft files updated whenever values are changed within the Controller.



The blocks of actions taken by each Vuser are
defined in Vu scripts created using Loadrunner's VuGen.exe. When this program is invoked, it stores in the Windows folder a comparamui.INI file to save under "[LastTablesUsed]" a history of files and [ParamDialogDates] specified using menu option Insert > New Parameter > Dates.

VuGen stores and retrieves a vugen.ini file in the Windows folder. When using Java, enable additional debug options:

[DynaDlg]
JavaLevel=3

When using 8.0 scripts within VuGen 8.1, add to Vugen.ini:

[Editor]
OLDEDITOR = 1

VuGen opens in LR folder template/qtweb default.cfg and script files.

Vu scripts can be coded to use variable values obtained from parameter files external to the script.

I have a lot more on VuGen here


During a run, execution results are stored to a results folder.
I prefer 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 I 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. See the ASP page I have written to access this 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.
To prevent errors when processing large result files, use MSDE (Microsoft SQL Desktop Engine). Don't install it from the Add-in folder on the LoadRunner 7.8 CD, which is obsolete SQL7. Download MSDE 2000 Release A which includes MSDE 2000 Service Pack 3a and MDAC 2.7 SP1a for use by Analysis on any Windows machine. Extract the file and share that folder. Open a command window to run a command such as:


setup SAPWD="StrongPassword" INSTANCENAME="LR" SECURITYMODE=SQL DISABLENETWORKPROTOCOLS=0 /L*v path to log file
Using Windows Explorer, share the Data folder.
Then in Analysis Options > Database tab, use 8.3 names without spaces (indentified with DOS command DIR /X):

Input the SAPWD password specified above.
Logical Storage location: \\loadclient02\Data (the folder you shared)
Physical Storage Location: C:\PROGRA~1\MICROS~1\MSSQL\Data (not C:\Program Files\Microsoft SQL Server\MSSQL\Data)
Click "Test parameters". (This takes a few seconds)

The Analysis Module (8,320K analysisu.exe)
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 formated in HTML.
Their format are controlled by a .tem template file.

Optionally, Mercury's Remote Performance Monitoring (RPM) MS-IIS/ASP web server for LoadRunner 7.8 can be installed on a Windows 2000 server ( but not on a Windows 2003 server) so that
load test results to be viewed using a web browser.

7 comments:

rg said...

LOL, I thought this was a website for the Sierra game.

Vishal sharma said...

I like the way you write about Load runner training in Noida. Awesome, keep it up.

bhanupratap said...

I prefer to study this kind of material. Nicely written information in this post, the quality of content is fine and the conclusion is lovely. Things are very open and intensely clear explanation of issues.... Best software Training institute in Bangalore

RPA Training in Hyderabad said...

nice post

RPA Training in Hyderabad

Sanvi said...

Great Article. Thanks for sharing info.

CEH Training In Hyderbad


Admin said...

These minimal information and facts will be built coupled with numerous track record information and facts. I favor this significantly.
BCOM 1st Year TimeTable 2020
BCOM 2nd Year TimeTable 2020
BCOM 3rd Year TimeTable 2020

Amrita Bansal said...

Awesome. You have clearly explained … It's very useful for me to know about new things. Keep on blogging.

Salesforce Admin training
Salesforce Development Training

Salesforce lightning training