loadrunner内部流程图

这是一个内部流程图,LoadRunner内部各个组件之间如何进行交互,数据流和文件流之间如何进行.

 

下面是各个步骤的简单介绍
1. application serverson this page under test are placed under stress by
2. 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:
(1). Kli> cpp (C language pre-processor) cci (C pre-compiling) which creaes a file with ci file, and
(2). 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.

3. virtual Vusers are invoked as groups (logical collection of virtual users running the same script on a specific load generator machine)
4. by agents (3,900K magentproc.exe) running as a service or as a processon this page
5. on load generator client machines.

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

9. 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.
10. Agents are launched by the Remote Agent Dispatcher process (formerly called Remote Command Launcher (RCL)) on each load generator machine.
11. Each agent refer to scenario (.lrs) definition files to determine which Vuser groups and scripts to run on host machines.

Idea 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 variableanother page on this site was updated to include where LoadRunner is installed.

12. 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.

Idea 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 fileanother page on this site to copy application-specific versions of ini files before executing wlrun. An example of file copy actions for application XXX:

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.

13. The blocks of actions taken by each Vuser are
14. defined in Vu scriptsanother page on this site 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. Mercury KnowledgeBase article 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 VuGenanother page on this site here

15. During a run, execution results are stored to a results folder.
Idea 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. tool See the ASP page I have written to access this databaseanother page on this site

16. 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 Vusers button then right-click on a group to select “Show Vuser Log”.

17. As a scenario is run, monitors maintain counters locally on each host.

18. After a run, the “collate” process takes .eve and .lrr result files and creates in the results folder a temporary .mdb (MS-Accessanother page on this site) 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):
1. Input the SAPWD password specified above.
2. Logical Storage location: \\loadclient02\Data (the folder you shared)
3. Physical Storage Location: C:\PROGRA~1\MICROS~1\MSSQL\Data (not C:\Program Files\Microsoft SQL Server\MSSQL\Data)
4. Click “Test parameters”. (This takes a few seconds)

19. [icon for Analysis module] The Analysis Module (8,320K analysisu.exe)
20. generates analysis graphs and reports using data from the .mdb database.
21. 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.
22. By default, the LRReport folder is created in the test analyst’s local machine My Documents folder to store Analysis Session files.
23. They can optionally be formated in HTML.
24. Their format are controlled by a .tem template file.

25. Optionally, Mercury’s Remote Performance Monitoring (RPM) MS-IIS/ASP web server for LoadRunner 7.8 can be installed on a Windows 2000 server (Caution! but not on a Windows 2003 server) so that
26. load test results to be viewed using a web browser.
Not pictured is the LoadRunner Tuning Module (a separate $50,000 product).