LoadRunner内部结构

转载自：http://blog.sina.com.cn/s/blog_6da75b980100n2nv.html

 

英文版地址： http://www.rickyzhu.com/21_principle-graph-of-loadrunner.html

原文请参考这里 http://www.wilsonmar.com/1loadrun.htm

 

 

1，             被测系统是由驱动进程mdrv.exe(多线程驱动的进程)和r3vuser.exe来产生压力的，其中r3vuser.exe仿真应用程序的客户端，如IE浏览器。它执行了三个主要的操作：

Kli> cpp (C 语言pre-processor)

1）cci （C语言编译器），建立ci文件，然后使用被测系统的协议相关的驱动来执行。

通过在Windows批处理脚本中启动Mdrv.exe来默默地启动运行。

Mdrv能自动停止加载Vuser，因为他们与Vuser和Windows负载生成器上的CPU使用监视器之间互相通信。

在Windows机器上，对于每一个基于Java的Vuser都有一个独立的JVM。

2，             虚拟用户通过在负载生成器客户端机器上使用agent（3900 magentproc.exe）作为服务或者进程来按照组（在指定的负载生成器上运行相同脚本的虚拟用户的集合）启动虚拟用户。

3，             每一个拥有代理的机器维护一个在.qtp文件中的执行日志。

4，             当日志被启用后，代理同样会在结果文件中为每一个虚拟用户（由虚拟用户组分开）建立一系列日志文件。

5，             在执行过程中， 这些文件可以通过在Controller机器上的view > Show Output窗口中显示。

6，             在预先设置延时上，Controller上运行的Scheduler指导代理(通过Windows 54345端口,或者Unix上的动态端口)去初始化场景会话.Controller(wlrun.exe)在请求中发送一份场景的拷贝.

7，             代理是由每一个负载生成器上的Remote Agent Dispatcher进程(以前叫Remote Command Launcher(RCL))启动的.

8，             每一个根据场景(.lrs)定义文件中设置的代理来决定哪一个虚拟用户组和脚本需要在主机上运行.

<!--[if !vml]-->

<!--[endif]--><!--[if !mso]-->

<!--[endif]-->

<!--[if !mso]-->

<!--[endif]--><!--[if !mso & !vml]--> <!--[endif]--><!--[if !vml]-->

<!--[endif]--> <!--[if !vml]--><!--[endif]-->## 这就是说Controller可以从DOS的批处理文件(.batch)中启动.

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

l      
包含的-Run 参数与手动的点”开始场景”自动运行是一样的.
这不是一个很好的方法,因为你可能需要决定从以前的运行中收集文件或者想改变输出文件夹.

l      
这是假设系统环境变量PATH已经被更新了,包括LoadRunner的安装.

9,
Controller通过使用    
Windows     
操作系统文件夹里的参数值来启动.因为LoadRunner被设计成在一个机器上一次只能运行一个Controller实例,所以需要使用Windows文件夹.

<!--[if
!vml]--><!--[endif]-->##
为了在几个应用之间快速的切换, 在Controller工作之后保存LoadRunner的ini文件,
然后使用记事本来制作一个批处理文件. 在执行wlrun之前拷贝应用程序的指定版本的ini文件.
下面是一个应用程序文件拷贝的例子:

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

需要修改一些默认值:

l      
在wlrun7.ini文件的output区域, MaxNumberOfOutputMessages= from 10000 to
100000, 这就限制了存储在数据库中的输出信息的数目.

l      
MaxOutputUIRowsToShow限制了在Controller的输出窗口中显示的信息/错误行总数.

l      
在LoadRunner程序文件的 dat\protocols  
文件夹下的QTWeb.lrp文件的[Vugen]部分,
添加一个MaxThreadPerProcess=5来限制由每个负载生成器mdrv.exe进程管理的线程数.

l      
存储在wlrun5.ini 和wlrun7.dft文件中的DefaultScenarioDir,
DefaultscrīptDir, DefaultResultDir, [Recent File
List]几个数据的值会在每次Controller改变的时候更新。

10，            
在Vu scrīpts中定义的每个虚拟用户进行的操作是用LoadRunner的VuGen.exe生成的. 当这个程序启动后,
它在windows文件夹下存储了comparamui.INI文件来保存[LastTablesUsed]下面文件的历史,并且保存由Insert
> New Parameter > Dates
菜单指定的[ParamDialogDates].

VuGen在Windows文件夹下存储和检索vugen.ini文件.当使用JAVA的时候,需要添加一些其他的调试选项:

[DynaDlg]
JavaLevel=3

当在VuGen 8.1中使用8.0的脚本, 往Vugen.ini中加入信息:

[Editor]
OLDEDITOR = 1

VuGen在LR文件夹template/qtweb
default.cfg里和脚本文件里打开.

Vu scrīpts可以使用脚本外部的参数文件来获得的变量值进行编码.

更多关于VuGen的信息请看脚本编写的章节.

11. 运行过程中,执行结果存储到一个结果文件夹中.

<!--[if
!vml]--><!--[endif]-->我喜欢在场景执行中把结果设置成自动产生结果.这样,LoadRunner会在每次启动一个场景之后自动产生一个子增的结果名.
例如,结果名称Res1会自动增长到Res12或有时候是R      
es11-1.

错误被写到output.mdb微软的Access数据库中。

12. 在每一个结果文件夹中, 程序自动创建Log文件夹来包含每个组的日志文件.
运行之后,在Controller中查看日志文件,点 <!--[if
!vml]--><!--[endif]-->,
.然后在组中点右键,选择 “Show Vuser Log”

13. 场景运行的时候, 监视器在本地维护每个主机的计数器.

14. 运行完成之后, "collate"进程处理.eve和.lrr结果文件,
并且在结果文件夹下创建一个临时的.mdb数据库.

在处理大数据量的结果时, 为了防止错误发生,使用MSDE. ……

15.分析模块(8,320K
analysisu.exe)使用mdb数据库中的数据来产生分析图表和报告.

16.
每一次场景运行后的结果文件results_name.lrr,也叫分析文档文件,由分析程序来读取并且显示百分位图表.

LoadRunner内部结构（2）

17. 默认的LRReport文件夹创建在本地分析机器的My
Documents文件夹下来存储分析会话文件.

18.可以使用HTML格式

19.格式是由.tem模版文件控制的.

20.可选的, LR7.8的Remote Performance Monitoring (RPM)
MS-IIS/ASP web server可以安装在Windows 2000 Server(但不是Windows 2003
Server)上,这样,负载测试的结果就可以使用web浏览器来浏览了.

Load Generator Agent进程和
Service

在安装过程中, 用户登陆页面:

l      
选择” Allow virtual users to run on this machine without user
login”意思是LoadRunner agent作为一个名称为LoadRunner Agent
Service的系统服务. 在Window的性能监视器中,这个图标名称为: magentservice.exe

<!--[if
!vml]--><!--[endif]-->为了更好的安全,指定一个独立的服务帐号,用户名和密码,这样可以限制权限.

安装完之后,为了测试是否能运行,

在Windows 2000, 上打开Start -> Control
Panel -> Administrative Tools ->
Services.
在  Windows NT4, 打开Start -> Control
Panel -> Services

你同样需要输入服务列表来改变密码,或者复位服务为"Automatic"

l      
选择” Manual log in to the Load Generator”意味着LoadRunner
agent按照名称为magenproc.exe的进程来运行.这种方法意味着你需要每次启动机器的时候从LoadRunner的
\launch_service\bin 手动运行Load Generator

<!--[if
!vml]--><!--[endif]-->magentproc.exe

你可以通过在windows任务栏中查看是否有卫星图标来判断是否在运行.

<!--[if
!vml]--><!--[endif]-->为了使机器每次重启都会自动运行Agent,可以在程序-à启动
这里建立一个快截方式.

<!--[if
!vml]--><!--[endif]-->作为一个进程,windows操作系统限制在运行的GUI(Winrunner, QuickTest
Professinail等)或者类似GUI脚本(Citrix, SAPGUI等)。因此，如果在负载生成器上的Remote Agent
Dispatcher安装成服务而不是进程的话，GUI和SAP Vuser就不能运行。

安装之后，为了把运行的LoadRunner由服务变成进程：

<!--[if
!vml]--><!--[endif]-->cd
\PROGRA~1\MERCUR~1\MERCUR~1\LAUNCH~1\bin
<!--[if
!vml]--><!--[endif]-->magentservice.exe
–remove

把LoadRunner作为服务安装：

<!--[if
!vml]--><!--[endif]-->magentservice.exe
–install

这些命令不会产生响应结果。但是把m_agent_attribs.cfg文件放到负载生成器的C:\根目录下。

如果你没有管理员权限，然后去试图改变用户ID：Admin，密码：Admin，你会看到这样的信息：

"29972:- Failed to reset launcher status call back
function reason:no monikor was passed.

在UNIX机器上，代理的配置是修改LoadRunner根目录下dat文件夹下的br_Inch_server.cfg实现的。

确保代理就绪

在控制器的负载生成器对话框中，在你点击“Connect”之后，你会看到“Ready”。

重新试验这些命令，直到你得到信息“Failed to connect to the agent。
Load Generator not responding after timeout Command line that was
executed”

如果这样仍然不能显示为“Ready”状态，在负载生成器的机器上看windows
服务，在重新使用上面的命令之前，kill 然后 删除“LoadRunner Agent Service”

设置FireWallServiceActive 1
为true，0为false。运行bin/agent_config

使用网络驱动映射

如果一些负载生成器需要访问相同的物理文件，而不是必须去记得每次文件改变后去拷贝这些文件，每一个负载生成器可可以使用映射驱动器来引用通用的文件夹。但是因为网络驱动映射是跟制定的用户关联的：

1，            
使用负载生成器要使用的用户来登录负载生成器的机器。

2，            
打开windows浏览器，在工具下选择映射一个网路驱动，然后创建一个驱动。

3，            
在服务中打开LoadRunner的服务。

4，            
点 登录 标签卡

5，            
指定负载生成器服务使用的用户名和密码（如果用户ID是本地域，用户名称这里会显示一个. ）

6，            
停止然后启动服务。

控制负载生成器，穿过防火墙来监控

防火器的目的是通过阻止一些通信来增强安全，它只允许一些特定的端口与外网通信，如HTTP的80和HTTPS的443端口。

默认的情况下，负载生成器通过MI Listener使用动态的端口发送信息的返回。

为了避免必须请求管理员来开放更多的端口，在防火墙内的每个负载生成器机器，从Start
> Programs > ... LoadRunner
> Advanced Settings > Agent
Configuration (launch_service\bin\AgentConfig.exe)，安装(Monitoring
Over Firewall machine) MoFW/RoWF agent，检查“Enable Firewall
Agent”选项。

它收集性能计数器的数据，并且穿过防火期发送这些数据给控制器。

MoFW与MI
Listener通过端口443来通信，所以机器上不要装有任何的Web服务器（Apache WebTours, IIS,或 Oracle
HTTP servers）

为了验证端口443是否允许通信，使用下面的命令：

<!--[if
!vml]--><!--[endif]-->telnet
  194.194.194.194   443

这会打开一个telnet窗口。

UNIX负载生成器使用一个动态的端口，这个端口不能固定。

当在控制器上定义一个远程的负载生成器时，在“Load Generator
Information”对话框上点“Details”，这里你可以点“Firewall”标签然后选择“Enable
Firewall”。

在windows和Unix/Liunx系统上监控资源

监控UNIX机器

在Liunx上启动监控之前，检查确保rstatd监控器是活动的。如果服务因为太忙或者重启而使rstatd服务停止，LR7.8就不能从rstatd中获得需要的信息了。需要退出或者重新初始化控制器。

HTTPS/SSL 通信的MI Listener

当代理从防火墙之后发送HTTPS通信，它会使用” Monitoring over Firewall
Component”，然后控制器为代理使用一个符号的名称，通过Mercury Interactive's MI Listener
Machine（通过端口50500）与外边的防火墙通信。通过防火墙监控WINDOWS机器使用TCP端口139。

为了测试外部的防火墙mercuryinteractive.com/products/protune_ds/ Mercury
ProTune Delivery Service

LoadRunner的工作原理图

下面一个是LoadRunner的工作原理图,更多的LoadRunner的理论请参考: http://www.wilsonmar.com/1loadrun.htm
wilson先生对LoadRunner有比较透彻的研究,这可以从他的分析中看出.

这张是LoadRunner的总体架构图,包括各个组件VUGen, Controller和Analysis之间的关系.

这是LoadRunner的工作原理,从图中可以看出如何利用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).

原文请参考这里 http://www.wilsonmar.com/1loadrun.htm

- See more at: http://www.rickyzhu.com/21_principle-graph-of-loadrunner.html#sthash.OX52qhHf.dpuf