【转载1】

正确选择协议，就要熟悉被测试应用的技术架构。以下列出一些LoadRounner支持的协议：

一般应用：C Vuser、VB Vuser、VB Script  Vuser、JAVA Vuser、JavaScript Vuser
电子商务：WEB（Http/Html)、FTP、LDAP、Palm、Web/WinsocketDual Protocol
客户端/服务器：MS SQL Server、ODBC、Oracle、DB2、Sybase CTlib、Sybase DBlib、Domain Name Resolution(DNS)、Windows Socket
分布式组件：COM/DCOM、Corba-Java、Rmi_Java
EJB：EJB、Rmi_Java
ERP/CRP： Oracle NCA、SAP-Web、SAPGUI、SAPGUI/SAP-Web Dual Protocol、PropleSoft_Tuxedo、Siebel Web、Siebel-DB2 CLI、Sieble-MSSQL、Sieble Oracle
遗留系统：Terminal Emulation (RTE)
Mail 服务：Internet Messaging(IMAP)、MS Exchange(MAPI)、POP3、SMTP
中间件：Jacada、Tuxedo 6、Tuxedo 7
无线系统：i-mode、voiceXML、WAP
应用部署软件：Citrix_ICA流：Media Plays(MMS)、Real 

【转载2】

一 段对于loadrunner协议选择的经典解答协议是数据在网络中传输的结构模式。协议不同，其数据报文的结构也有所不同。 协议是有层次的，一般我们从ip层开始，往上有TCP协议层，UDP协议层，而TCP和UDP协议层上又有http协议层，ftp协议层，smtp协议层 等我们在lr中看到的这些应用层的协议。 其实这些高层协议都是对底层协议进行的进一步封装。举个简单例子，本来IP协议的数据报文是无序，不是可靠传输的，在其数据报文外面增加了报文序号，报文 状态等数据段就构成了TCP协议层。 所以我们很多网络应用，没有找到合适的协议，就用winsock来录制，那是肯定没有问题的。因为几乎所有的网络传输中都是基于tcp协议或udp协议 的，而socket正是这一级上的概念。但是由于socket协议级别太低，你录下来的东西是很难理解的，都是socket，port，data之类的东 西。所以，我们尽量用高层协议来录制，我们就能看懂了。

话要再说回来，解决一下具体的问题。我们看到一个软件体系架构，应该怎样选择录制协 议呢？说到这里，我要说一下自己对lr录制机理的理解（我没有接触过lr内核，只是凭猜测和推断）。在录制时，lr应该会对你从本机发出去的数据进行截 包，并拆包。因为我们知道协议的不同就是体现在数据包的结构不同，lr应该通过对包结构的分析，判断是不是它支持的协议，对包数据的分析，来获取用户发送 的东西。 比如你用ftp的协议去录制一个访问网页的IE操作，那肯定是无所收获的。因为lr没有在网络截获到ftp协议格式的包，都是http协议格式的包，它不 认，当然就是一个录制为空的结果了。 现在我们弄懂了这个事情，就知道该如何选择协议了。看见很多人关心lr是不是支持mysql协议。我认为要寻找的答案的思路是这样的：

1、首先弄清mysql协议和其他数据库协议的关系，看能不能用其它数据库协议录制。但其实oracle的cs协议是oracle独有自己开发的协议，sqlserver也是一样，而mysql又与这几大产品又不是隶属关系，其脚本录制的可能性很小。
2、mysql协议的底层是基于什么协议的，如果直接构建在tcp协议上，lr又不支持mysql协议，那只能考虑用低一点的协议录录看，即socket。如果mysql协议是构建在odbc协议上的，那么就可能用lr的odbc api来写。 

【转载3】

很 多时候一提到不是基于浏览器的应用，很多人就会想到用WinSocket协议来录制，仿佛Form窗体都可以用Winsocket 。从道理上讲网络通讯的底层都是基于Socket的，例如TCP、UPD等，似乎所有的程序都可以用Socket协议来录制。但是事实不是这样的，因为选 择的协议决定了LoadRunner如何捕获数据包。否则会多捕获很多无用的数据。因此，不是所有的程序都是适合WinSocket协议的。实际上，那些 基于Socket开发的应用才真正适合Socket协议来进行录制。其他的，例如基于数据库的应用，就不太时候Socket协议，甚至可能录制不到脚本。 很多C/S程序，一定要选择合适的协议。根据作者的经验，C/S的程序多数需要手工开发很多脚本，因为录制的很多回放时候或多或少都会有些问题，但是可以 参考录制的结果。所以测试一个程序，一定要搞清楚开发人员用了什么技术、数据流是什么协议封装的。理论上来说我们在对一个系统做性能测试以前，要先和开发 人员了解一下他们在开发过程中都用了些什么技术，数据流是用什么协议封装的，还要了解我们要测试的系统的网络结构，服务器的配置等问题；还有就是要知道系 统客户端和第一服务器间的协议，这中间就涉及到一个中间件的问题。另外我们要知道协议的选择直接关系到LR会捕获到什么样的数据包。这些是进行性能测试的 基础。 下面说几个测试的原则（都是自己遇到过的，呵呵，没遇到过的就不知道了）：

1、一般情况下b/s构架的只要 选择WEB（Http/Html)协议就可以了，如果有中间件的则选择中间件服务器的协议 ；
2、C/S结构，可以根据后端数据库的类型来选择。如SybaseCTLib协议用于测试后台的数据库为Sybase的应用；MS SQL Server协议用与测试后台数据库为 SQL Server的应用；
3、 一般不是基于浏览器的，对于一些没有数据库的Windows应用，我们在测试的过程中都会选择WinSocket协议来录制，理论上来讲我们这样选择是正 确的，但我们要知道在录制的时候所选择的协议就决定了LR如何捕获数据包，如果我们选择错误了，将会捕获到一些无用的数据包。cs结构是比较复杂的，在这 里我要提醒大家，一定要搞清楚cs是client-database还是client-server-database结构的，只有这样我们才能够决定是 选择WinSocket协议还是sql协议，或者说选择多个协议；当然协议的选择也是一个探索的过程，只要能够得到我们想要的结果，那就是正确的。还有一 点，我们在做性能测试的时候应该是有测试重点的，呵呵。
4、关于单协议和双协议，我只知道IE6内核的浏览器在录制脚本的时候要选择单协议，而IE7内核的浏览器在录制脚本的时候要使用双协议。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1735726

Correlating Statements Functions

Click one of the following functions for more information:

===Great Work!

Today, I plan to share my experience on the memory leaks detecting. This article is a step-by-step instruction on how to use HP/Mercury LoadRunner to perform load testing for the purpose of memory leaks discovering.


The task:
It needs perform testing of Web server to discover memory leaks.

The solution:

1. Create LoadRunner VuGen scrīpt for your application (Web server in my scrīpt)
   Let's suppose, we have done it:
   
   Actually, I will explain different tricks and features of VuGen scrīpts in the further posts.
   
2. Create LoadRunner Controller scenario for your application using the VuGen scrīpts.
   Here it is:
   
   
3. The next step is to add measurement monitors which are quantitative indicators of resources being monitored (for example, memory usage, CPU usage, handle and thread count, and so on).
   For that, on "Run" tab in the LoadRunner Controller, drag "Windows Resources" item from the "Available Graphs" tree and drop it to graphs area.
   See the screenshot:
   
   Then right-click on the just added graph ("Windows Resources") and select "Add Measurements" from the pop-up menu.
   "Windows Resources" dialog will be shown:
   
   The following actions are easy. I will add the name of server where the application (Web server in my case) will be run. This server can be a remote one. In this case, you have to make sure that LoadRunner will have an access to get info from the remote computer. Usually, I provide administrator rights for user which executes LR scrīpts.
   After that I select counters I want to measure during the load testing:
   
   So, "Windows Resources" dialog looks like:
   
   I selected the following counters:
   
   • % User Time for two processes (RService & tomcat5) and the whole system (_Total)
   • Available bytes in the system
   • Handle counts
   • Thread counts
     
   • Working Sets
   Also you may wish to add "Private Bytes" counter. Descrīption for each counter is available on "Windows Resources" dialog. Obviously that the set of counters depends on the requirements and software to be tested.
   
   Pay attention... If you select the "Windows Resources" graph, the list of counters will be shown in the lower part of the LoadRunner Controller:
   
   
4. Our mission is almost complete :) We have to run the scenario against a number of concurrent users (I user 30 users) and observe the graph displaying info on memory, CPU, handles and so on...
   I will show the result graph after 4 hrs of execution:
   
   Pay attention to the yellow dotted line (memory usage of "RService" process) and the brown dotted line (habdle count counsumed by "RService" process) trends. They grow constantly during ~ 4.5 hours. I marked them out with red lines.
   So, this graph provides proofs that the application, I tested, contains memory leaks in the "RService" process.
   
   Several words about useful tricks and hints, connected to measurements ans graphs:
   
   • It is possible to export graphs to HTML from the LR. For that, right-click on the graph and select "Export to HTML...". It will generate HTML report containing the graph and a legenda for it. Very useful feature :)
   • I recommend to set the range of time to be shown on the graph, to "Relative to scenario start". To perform this, right-click on the graph and select "Configure...". That allow to display statistics for the whole execution, but the latest N minutes.
     
   • Sometimes, it is convenient to show more detailed graph. For that, double click on the graph - one big graph will be shown. To revert, double-click again. Also, you can change the number of graphs displayed - open menu View/View Graphs and set the required number.
     
     
5. So, now Dev team has to fix the problem in the "RService" process.. The last graph shows the results of load testing perfomed on the fixed application:
   
   No any memory leaks found during 10 hrs.
   
   Memory leaks fixed! Isn't it a progress? :)

       在LR下也可以直接调用动态链接库文件，针对一些使用LR脚本编写比较烦琐的方法可以考虑此方法（比如各种加解密算法的实现，数据库的操作等），并能够使测试脚本简单明了。鉴于此，本人初次尝试了如何制作DLL文件并在LR中使用。

       1、dll文件的制作

       在Visual C++6.0开发环境下，打开File-New-Project选项，可以选择Win32 Dynamic-Link Library来创建一个名为dllfortest的空的dll工程（这只是方法之一）。

       在该项目中新建一个dllfortest.h和dllfortest.cpp文件，文件的内容如下:

//dllfortest.h

extern "C" _declspec(dllexport) int Max(int a, int b, int c);

extern "C" _declspec(dllexport) int Min(int a, int b, int c);

//dllfortest.cpp  包含一个计算三个整数中最大值和最小值的方法

#include"dllfortest.h"

int Max(int a, int b, int c)

{

       int Res;

       Res = (a>b? a:b)>c? (a>b? a:b):c;

       return Res;

}

int Min(int a, int b, int c)

{

       int Res;

       Res = (a>b? b:a)>c? c:(a>b? b:a);

       return Res;

}

该动态链接库编译成功后，打开dllfortest工程目录下的debug目录下，可以看到生成了一个dllfortest.dll文件，这就是我们想要的文件。

       2、dll文件在LR中的调用

       打开LR VU Generator，选择C Vuser协议（或其他支持C的协议），进入编辑界面。Action部分如下所示：

Action()

{

       lr_load_dll("dllfortest.dll");

       lr_message("Max Result is %d",Max(100,200,67));

       lr_message("Min Result is %d",Min(55,97,63));

       return 0;

}

将dllfortest.dll文件复制到脚本所在的目录（如果不复制的话，lr_load_dll的参数应该写成dll文件的绝对路径），如果编译没有报错的话，就可以直接运行了。

运行结果如下：

Virtual User scrīpt started

Starting action vuser_init.

Ending action vuser_init.

Running Vuser...

Starting iteration 1.

Starting action Action.

Max Result is 200

Min Result is 55

Ending action Action.

Ending iteration 1.

Ending Vuser...

Starting action vuser_end.

Ending action vuser_end.

Vuser Terminated.

如果在脚本中用到了DLL文件中并不存在的方法名时，编译也能通过，但是运行时LR会报错，提示不存在该方法

比如我们在脚本中添加一句：

       lr_message("Min Result is %d",Sum(55,97,63));  //Sum方法并不存在

运行时错误信息如下：

Action.c(7): Error: C interpreter run time error: Action.c (7):  Error -- Unresolved symbol : Sum.

Action.c(7): Notify: CCI trace: Compiled_code(0): Action()

.

这个例子并没有体现出DLL文件调用的优点，因为调用的方法在LR中用C直接就可以完成，但涉及到LR中完不成的任务时，或许dll文件的作用就体现出来了

example：
LoadRunner提供了功能强大的API集合，足够应付大多数性能测试的需求。但在某些情况下，这些API仍然有覆盖不到的地方。例如，我们有一个WEB应用，该应用有一个页面输入用户的信息，为了安全起见，用户输入的信息在提交之前都要先进行加密处理，加密处理通过本地的COM组件实现。

对这个要求而言，LoadRunner的现有API不能提供直接支持，因为LoadRunner在录制脚本时只录制数据交互，因此，COM的加密处理过程是不能录制下来的。在LoadRunner的脚本中，可能只有类似以下的语句描述了这个过程：

…………
web_url("userinfo",
    "URL=http://testweb/userinfo.aspx",
    "TargetFrame=",
    "Resource=0",
     "Referer=",
     LAST);

web_submit_form("login ",
"Snapshot=t4.inf",
ITEMDATA,
"Name=username", "Value=4e92Sh6d394g", ENDITEM,
"Name=password", "Value=932A2hf34U18", ENDITEM,
LAST);
…………

从脚本可以看到，输入的数据是加密后的数据，但LR没有录制到加密过程。

假设加密函数所在的DLL名为security.dll，用于加密的函数名为encode，则一种可能的对脚本的修改方法如下代码所示。
…………
char *encode_username, *encode_password, *orgin_username, *orgin_password;
char* uservalue, passvalue;
int ret;
……
web_url("userinfo",
     "URL=http://testweb/userinfo.aspx",
     "TargetFrame=",
     "Resource=0",
      "Referer=",
      LAST);

orgin_username = lr_eval_string(“{ username }”); //获取参数的值
orgin_password = lr_eval_string(“{ password }”);

ret = lr_load_dll(“security.dll”);   //加载DLL库

encode(origin_username, encode_username);  //调用encode函数
encode(origin_password, encode_password);

sprintf(uservalue, “Value=%s”, encode_username);
sprintf(passvalue, “value=%s”, encode_password);

web_submit_form("login ",
  "Snapshot=t4.inf",
  ITEMDATA,
  "Name=username", uservalue, ENDITEM,
  "Name=password", passvalue, ENDITEM,
  LAST);


注意：有些脚本录制需要相应的patch的支持，如录制DotNet编写的应用程序你需要把lr78安装盘\ Patches\Trap_for_.net_patch文件夹中trpfnc32.32dll拷贝到loadrunner\bin路径下，才能正常工作。

最近老是看见有tx对在Controller中添加系统资源Monitor连接不上的问题，为此查了Controller的说明，上面对以下情况作了解释，同学们看看，应该大部分问题都能解决了。反正还是建议大家要多看看帮助，呵呵

监控windows配置：
一  windows

  1  监视连接前的准备工作

      首先保证被监视的windows系统开启以下二个服务Remote Procedure Call(RPC)   和Remote Registry Service   (这里具体在那里开起服务就不说了)

   被监视的WINDOWS机器:右击我的电脑,选择管理->共享文件夹->共享  在这里面要有C$这个共享文件夹,(要是没有自己手动加)

     然后保证在安装LR的机器上使用运行.输入\\被监视机器IP\C$  然后输入管理员帐号和密码,如果能看到被监视机器的C盘了,就说明你得到了那台机器的管理员权限,可以使用LR去连接了

  
  说明: LR要连接WINDOWS机器进行监视貌似要有管理员帐号和密码才行,

2  用LR监视windows的步骤

      (这里就不详细说明了,只要在窗口中右击鼠标选择Add Measurements就可以了)

Q1：无法Monitor在另一个domain的Windows主机或者报错"Access Denied"
A1：获取远程主机的管理员权限，在命令行模式下运行如下命令
        Net use \\<主机名>
        在弹出的用户名提示后输入远程主机的用户名，在弹出的密码提示后输入远程主机密码

Q2：无法Monitor一个NT/2000的主机，报错"computer name not found"或"connot connect to the host"
A2：远程主机只允许具有管理员权限的用户Monitor资源，若需要非管理员也能够获得资源信息，需要手工授权"Read"权限给某些文件和注册表项。具体步骤如下：
1、        授权给用户以下文件的读权限
a)        %windir%\system32\PERFCxxx.DAT
b)        %windir%\system32\PERFHxxx.DAT
其中xxx是系统的基础语言id，如英语就是009，如果找不到文件，最好从安装光盘中copy出来
2、        在注册表中查找以下表项并授予读权限
HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Perflib以及其子项
3、        在注册表中查找以下表项并授予读权限
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\winreg

Q3：从WinNT主机上无法获得一些Win2000下的计数器
A3：在Win2000主机上运行Controller或Tuning

Q4：一些Windows的默认计数器报错
A4：把报错的计数器删除并添加更合适的计数器

Q5：无法获得目标主机上SQL Server（version 6.5）的性能计数器
A5：这是6.5版本的SQL Server的一个bug，需要手工在被监控主机的注册表中赋予以下表项读权限
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer

Q6：选中的measurement参数没有显示在图表中
A6：确定display file和online.exe已经被注册。运行loadrunner\bin下的set_mon.bat文件

Q7：在Monitor Windows主机时，在图表中没有出现任何参数
A7：查看Windows主机中的Windows Performance Monitor，如果没有出错，则查看通讯设置

Q8：在Monitor Unix主机时，在图表中没有出现任何参数
A8：确保Unix主机上rstated进程已经运行

Q9：无法监控如下的Web服务器：Web IIS、MS ASP、ColdFusion
A9：同Q7

Q10：无法监控WebLogic（JMX）服务器
A10：打开LoadRunner\dat\monitors\WebLogicMon.ini文件，查找以下字符串：
[WebLogicMonitor]
JVM=javaw.exe
把javaw.exe替换成java.exe

Web Resources（Web资源分析）
Web资源分析是从服务器入手对Web服务器的性能分析。
1、Hits per Second（每秒点击次数）
“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
2、Throughput（吞吐率）
“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。
可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
“吞吐率”图和“点击率”图的区别：
“吞吐率”图，是每秒服务器处理的HTTP申请数。
“点击率”图，是客户端每秒从服务器获得的总数据量。
3、HTTP Status Code Summary（HTTP状态代码概要）
“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。
4、HTTP Responses per Second（每秒HTTP响应数）
“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。
5、Pages Downloader per Second（每秒下载页面数）
“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。
和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。
注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。
6、Retries per Second（每秒重试次数）
“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。
在下列情况将重试服务器连接：
A、初始连接未经授权
B、要求代理服务器身份验证
C、服务器关闭了初始连接
D、初始连接无法连接到服务器
E、服务器最初无法解析负载生成器的IP地址
7、Retries Summary（重试次数概要）
“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。
8、Connections（连接数）
“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。
借助此图，可以知道何时需要添加其他连接。
例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。
9、Connections Per Second（每秒连接数）
“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。
理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。
10、SSLs Per Second（每秒SSL连接数）
“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。

Web Page Breakdown（网页元素细分）
“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的
元素。
1、Web Page Breakdown（页面分解总图）
“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。
“页面分解”图可以按下面四种方式进行进一步细分：
1)、Download Time Breaddown（下载时间细分）
“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。
2)、Component Breakdown(Over Time)（组件细分(随时间变化)）
“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。
3)、Download Time Breakdown(Over Time)（下载时间细分(随时间变化)）
“下载时间细分(随时间变化)” 图显示选定网页的页面元素下载时间细分（随时间变化）情况，它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。
“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页面元素的下载时间。
4)、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）
“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一次缓冲之前的这段时间，场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间（以秒为单位）。可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。
First Buffer Time：是指客户端与服务器端建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端，到浏览器接收到第一个缓冲所用的时间。
2、Page Component Breakdown（页面组件细分）
“页面组件细分”图显示每个网页及其组件的平均下载时间（以秒为单位）。可以根据下载组件所用的平均秒数对图列进行排序，通过它有助于隔离有问题的组件。
3、Page Component Breakdown(Over Time)（页面组件分解(随时间变化)）
“页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间 （以秒为单位）。
4、Page Download Time Breakdown（页面下载时间细分）
“页面下载时间细分”图显示每个页面组件下载时间的细分，可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。
“页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。
5、Page Download Time Breakdown(Over Time)（页面下载时间细分(随时间变化)）
“页面下载时间细分(随时间变化)”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。
“页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图通常结合起来进行分析：首先确定有问题的组件，然后分析它们的下载过程，进而定位原因在哪里。
6、Time to First Buffer Breakdown（第一次缓冲时间细分）
“第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有关。
网络时间：定义为第一个HTTP请求那一刻开始，直到确认为止所经过的平均时间。
服务器时间：定义为从收到初始HTTP请求确认开始，直到成功收到来自Web服务器的一次缓冲为止所经过的平均时间。
7、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）
“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的服务器时间和网络时间。可以使用此图确定场景运行期间服务器或网络出现问题的时间点。
8、Downloader Component Size(KB)（已下载组件大小）
“已下载组件大小”图显示每个已经下载的网页组建的大小。通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能。

简单介绍一下Loadrunner Analysis中的Web Page Diagnostics模块的使用，很多人对于测试之后的结果数据分析摸不着头脑，其实loadrunner Analysis给你提供了很好的文档，大家没事可以多翻翻，多翻几遍对于性能测试你就入门了 ；）

Web Page Diagnostics （以下简称WPD），这是LR Analysis中非常重要的一块，搞清楚这部分的内容会让你少走很多弯路，很多环境问题都可以通过它来定位，比如客户端，网络。通过它可以你可以比较好的来定位是环境的问题还是应用本身的问题，当然更重要的是Web页面本身的问题。

WPD包括下面几个图表：

Web Page Diagnostics     这是张总图，包括下面几张Over Time图的内容

Page Component Breakdown     页面中每个元素的平均响应时间占整个页面响应时间的百分比

Page Component Breakdown(Over Time)     在整个测试过程中，任意一秒内页面中每个元素的响应时间（例如在runtime中设置了browser cache，页面中的资源文件就只会在第一次下载，后面的页面响应时间也就不包括这些元素的时间，这在Page Component Breakdown中是看不出来的，因为Page Component Breakdown是整个测试期间内的平均时间。当然，是否启用了cache，通过over time图就能看出来）

Page Download Time Breakdown    页面中每个元素的响应时间分割图，响应时间被分割为以下几个部分：DNS Resolution,Connection,First Buffer,SSL Handshaking,Receive,FTP Authentication,Client,Error

Page Download Time Breakdown(Over Time)      在整个测试过程中，任意一秒内页面中每个元素的响应时间分割图

Time to First Buffer Breakdown      First Buffer Time时间分割为Network Time和Server Time，客户端http请求发送到接收到服务器端的应答包（ACK）为Network Time，从接收到ACK到完成First Buffer接受为Server Time

Time to First Buffer Breakdown(Over Time)      基本同上，任意一秒内的

Downloaded Component Size(KB)      页面中每个元素的大小（KB）

介绍了这么多，具体如何分析呢？

首先打开Web Page Diagnostics图，来看看下面一个例子Download Time图：

上图存在两个问题：

1、receive时间很长

这个一般是网络问题，当然如果你确认网络不存在问题，那么你就要看看是不是客户端的问题（客户端也可能会造成Receive过长，这个千万要注意）

2、页面问题

页面上包括了非常多的图片，而且图片似乎都没有优化，最大的竟然有163K，记下来，这可是罪证哦 ；）

很多时候，你可以根据DNS,Connection,Receive来看出是否存在网络问题，根据Client来判断是否存在客户端问题。

看看，挺简单的吧！ ^_^

换个图看看，Page Component Breakdown(Over Time)

很清楚吧，页面元素都被cache了，说明场景启用了browser cache，页面的响应时间只包括红线和蓝线。

Time to First Buffer Breakdown(Over Time)  ，图就不贴了，这个图非常重要，也最复杂，这里的值不绝对，当网络状况不好的时候，server time很可能包括网络时间，因为很多页面元素比较小（小于4k的样子），在First Buffer就完成传输，所以一定要注意分析。

就唠叨到这里吧，欢迎拍砖

LR调用：
你把dll拷贝到LRscripts中就成了！或者按照如下方式加载：
全局的动态链接库的调用则需要修改mdrv.dat，路径在LoadRunner的安装目录下面（LoadRunner/dat directory）；在里面修改如例：
[WinSock]
ExtPriorityType="protocol"
WINNT_EXT_LIBS="wsrun32.dll"
WIN95_EXT_LIBS="wsrun32.dll"
LINUX_EXT_LIBS="liblrs.so"
SOLARIS_EXT_LIBS="liblrs.so"
HPUX_EXT_LIBS="liblrs.sl"
AIX_EXT_LIBS="liblrs.so"
LibCfgFunc="winsock_exten_conf"
UtilityExt="lrun_api"
ExtMessageQueue="0"
ExtCmdLineOverwrite="-WinInet" No
ExtCmdLineConc="-UsingWinInet" No
WINNT_DLLS="user_dll1.dll," user_dll2.dll, ...
//最后一行是加载你需要的DLL

LR脚本示例：
char msgid[80],sp[20];
lr_load_dll("GetData.dll");
i=init_db("DRIVER={SQL Server};SERVER=*****;UID=******;PWD=*****;DATABASE=******");
lr_output_message("i=%d",i);
i+=execSQL("select top 1 org_msgid,sp_number from msg");
lr_output_message("i=%d",i);
i+=bindCol(1,msgid,"c",77);
i+=bindCol(2,sp,"c",6);
lr_output_message("i=%d",i);
i+=fetchData();
lr_output_message("i=%d",i);
lr_output_message("i=%s",msgid);
lr_output_message("i=%s",sp);
disConnect();

在判断结束100为记录的结束的标识符，在调用DLL之初、结束以及出错时自动将日志输出到当前目录的dll.log中去！
程序参考：
int i=0;
int j;
char msgid[80],sp[20];
lr_load_dll("GetData.dll");
i=init_db("DRIVER={SQL Server};SERVER=*****;UID=**;PWD=***;DATABASE=*****");
lr_output_message("i=%d",i);
i+=execSQL("select top 10 org_msgid,sp_number from msg");
lr_output_message("i=%d",i);
i+=bindCol(1,msgid,"c",77);
i+=bindCol(2,sp,"c",6);
lr_output_message("i=%d",i);
while (i!=100)
{
i=fetchData();
lr_output_message("i=%d",i);
lr_output_message("i=%s",msgid);
lr_output_message("i=%s",sp);
}
disConnect();

新增加init_hstmt（）以及disConnect_hstmt（）两个API
init_hstmt()函数将传出一个long类型的hstmt变量,调用方式：

long hstmt;
init_hstmt(&hstmt);

disConnect_hstmt(hstmt);

--------------------------------------------------------------------------------

GetData.dll
 描述: 获取数据库中的值
 
 文件大小:  208.05 KB

要监控服务器计算机上的资源，必须能够连接到该计算机。如果监控失败，并且 LoadRunner 找不到指定的服务器，请确认指定的服务器是否可用。在 Controller 或优化控制台计算机命令行中键入 ping <server_name> ，执行 “ping” 操作。

验证可以访问该计算机后，请查看下表中有关监控器疑难解答的其他提示。

问题	解决方案
无法监控其他域中的 Windows 计算机，或者“访问被拒绝”。	要获得对远程计算机的管理权限，请在命令提示符下执行以下命令： %net use \\<计算机名>/用户:[<域>\<远程计算机名>] 提示输入密码时，输入远程计算机的密码。
无法监控 NT/Win 2000 计算机（发出一条错误消息：“未找到计算机名”或“无法连接到主机”）	要监控的 NT/Win 2000 计算机仅允许具有管理员权限的用户进行监控。要允许非管理员用户进行监控，必须授予用户对特定文件和注册表项的读取权限（Microsoft 技术说明编号 Q158438）。需要执行下列步骤： a. 使用浏览器或文件管理器，授予用户对下列项的读取权限：        %windir%\system32\PERFCxxx.DAT        %windir%\system32\PERFHxxx.DAT     其中 xxx 是系统的基本语言 ID，     例如，英语的 ID 为 009。这些文件可能     已丢失或损坏。如果对此有怀疑，请从     安装 CD 中提取这些文件。 b. 使用 REGEDT32，授予用户对下列项的读取权限：    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Perflib     以及该项的所有子项。 c. 使用 REGEDT32，至少授予用户对下列项的读取权限：     HKEY_LOCAL_MACHINE\System\CurrentControlSet\    Control\SecurePipeServers\winreg
无法从 NT 计算机监控某些 Win 2000 计数器。	在 Win 2000 计算机上运行 Controller 或优化控制台。
某些 Windows 默认计数器生成错误	删除有问题的计数器，并使用“添加度量”对话框添加相应计数器。
无法从被监控的计算机上获得 SQL Server 6.5 版的性能计数器。	这是 SQL Server 6.5 版的一个错误。解决方法为：在被监控的计算机上使用 regedt32，授予用户对以下注册表项的读取权限： HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer （Microsoft 技术说明编号 Q170394）
选定度量未显示在图中。	确保已注册显示文件和 online.exe。要在不执行完全安装的情况下注册监控器的 dll，请运行LoadRunner\bin中的set_mon.bat批处理文件。
监控 Windows 计算机时，图中不显示任何度量。	检查内置的 Windows 性能监控器。如果该监控器不能正常工作，则可能是通信设置有问题。
监控 UNIX 计算机时，图中不显示任何度量。	确保rstatd正在 UNIX 计算机上运行（请参阅“系统资源监控”）。
无法监控下列 Web 服务器之一：MS IIS、MS ASP 或ColdFusion	请参阅上面的问题“无法监控 Windows 计算机”。
无法监控 WebLogic (JMX) 服务器	打开<LoadRunner 根文件夹>\dat\monitors\WebLogicMon.ini文件，并搜索： [WebLogicMonitor] JVM=javaw.exe 将 javaw.exe 更改为 java.exe。将打开一个包含跟踪信息的窗口。

CPU信息：
Processor\ % Processor Time 获得处理器使用情况。
也可以选择监视 Processor\ % User Time 和 % Privileged Time 以获得详细信息。
Server Work Queues\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。
System\ Processor Queue Length 用于瓶颈检测
通过使用 Process\ % Processor Time 和 Process\ Working Set
Process\ % Processor Time过程的所有线程在每个处理器上的处理器时间总和。

硬盘信息：
Physical Disk\ % Disk Time
Physical Disk\ Avg.Disk Queue Length
例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
Physical Disk\ % Disk Time
Physical Disk\ Avg.Disk Queue Length
例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
请观察 Processor\ Interrupts/sec 计数器的值，该计数器测量来自输入/输出 (I/O) 设备的服务请求的速度。如果此计数器的值明显增加，而系统活动没有相应增加，则表明存在硬件问题。
Physical Disk\ Disk Reads/sec and Disk Writes/sec
Physical Disk\ Current Disk Queue Length
Physical Disk\ % Disk Time
LogicalDisk\ % Free Space
测试磁盘性能时，将性能数据记录到另一个磁盘或计算机，以便这些数据不会干扰您正在测试的磁盘。
可能需要观察的附加计数器包括 Physical Disk\ Avg.Disk sec/Transfer、Avg.Disk Bytes/Transfer，和 Disk Bytes/sec。
Avg.Disk sec/Transfer 计数器反映磁盘完成请求所用的时间。较高的值表明磁盘控制器由于失败而不断重试该磁盘。这些故障会增加平均磁盘传送时间。对于大多数磁盘，较高的磁盘平均传送时间是大于 0.3 秒。
也可以查看 Avg.Disk Bytes/Transfer 的值。值大于 20 KB 表示该磁盘驱动器通常运行良好；如果应用程序正在访问磁盘，则会产生较低的值。例如，随机访问磁盘的应用程序会增加平均 Disk sec/Transfer 时间，因为随机传送需要增加搜索时间。
Disk Bytes/sec 提供磁盘系统的吞吐率。
决定工作负载的平衡
要平衡网络服务器上的负载，需要了解服务器磁盘驱动器的繁忙程度。使用 Physical Disk\ % Disk Time 计数器，该计数器显示驱动器活动时间的百分比。如果 % Disk Time 较高（超过 90%），请检查 Physical Disk\ Current Disk Queue Length 计数器以查看正在等待磁盘访问的系统请求数量。等待 I/O 请求的数量应当保持在不大于组成物理磁盘的主轴数的 1.5 到 2 倍。

尽管廉价磁盘冗余阵列 (RAID) 设备通常有多个主轴，大多数磁盘有一个主轴。硬件 RAID 设备在“系统监视器”中显示为一个物理磁盘；通过软件创建的 RAID 设备显示为多个驱动器（实例）。可以监视每个物理驱动器（而不是 RAID）的 Physical Disk 计数器，也可以使用 _Total 实例来监视所有计算机驱动器的数据。

使用 Current Disk Queue Length 和 % Disk Time 计数器来检测磁盘子系统的瓶颈。如果 Current Disk Queue Length 和 % Disk Time 的值始终较高，可以考虑升级磁盘驱动器或将某些文件移动到其他磁盘或服务器。

From: http://bbs.51testing.com/thread-2196-1-1.html