Loadrunner对Linux的监控点不是很多，分析起来很费力，看到不少人都提到了nmon就试用了一下， 感觉还不错，就是有个缺点，与Loadrunner的场景执行时间有个时间差的问题，但是个人认为最终数据虽然会有些偏差，但是不影响性能分析，这个因素 可以忽略掉

nmon用起来很简单，无需安装，解压后直接就可以使用了
一、下载
nmon下载地址：http://www-941.haw.ibm.com/collaboration/wiki/display/WikiPtype /nmon

nmon还带了个分析工具，下载地址：http://www-941.haw.ibm.com/collaboration/wiki /display/Wikiptype/nmonanalyser

二、安装
下载完成后，把压缩包解压，上传到服务器的任意目录，如/usr/local/nmon
我的服务器是Redhat server 5.3的，发现虽然没有对应的5.3的版本，下载5.2的也可以使用

三、启动
打开nmon所在的目录：cd /usr/local/nmon
修改启动文件的访问权限：chmod 755 nmon_x86_rhel52
启动nmon：./nmon_x86_rhel52
如果要采样nmon的数据保存成文件，可以
./nmon_x86_rhel52 -fT -s 30 -c 120
其中30表示每隔30秒nmon取一次系统性能数据，120表示取120次；
这样nmon将会在运行开始算起连续取得30sX120=60分钟，可根据实际需要时间调整；当运行以上命令后该目录下会生成一个.nmon文件，该文件 会根据间隔时间被写入性能数据，当一段时间后再查看该文件，文件字节变大

未完待续

Error -27796: Failed to connect to server “127.0.0.1:80″: [10060] Connection timed out

该问题通常是因为负载生成器，发数据包太快，服务器响应也快，从而导致负载生成器的机器的端口在没有timeout之前就全部占满了。在全部占满 后，就会出现上面的错误

如果是这个问题，可以通过修改负载机注册表来解决
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 里，有如下两个键值：TcpTimedWaitDelay和MaxUserPort
TcpTimedWaitDelay通常系统默认是30s，可以调小一下试试。MaxUserPort可以调大。

【TcpTimedWaitDelay】值决定了TCP/IP必须经过多久，才能释放出已关闭的连接及重复使用它的资源。这个关闭和释放的间隔称为 TIME_WAIT状态，或是区段生命期限上限 (2MSL)状态的两倍。在这段时间内，通往用户端和伺服器的连接重新开启的成本比建立新的连接低。如果减小这个键值，TCP/IP 可以更快释放出已关闭的连接，提供更多资源给新的连接。如果执行中的应用程式需要快速释放、建立新连接，或多个连接在 TIME_WAIT 状态中造成通讯量太低，因此可以考虑调小这个值。

主要是受采样时间的影响。 Summary里的事务平均响应时间是根据整个场景执行过程得到的数据计算所得，最大值与最小值也是从整个场景中得到的。平均事务响应时间图主要时按照 LoadRunner分析出来的采样频率来获取事务响应时间的最大值与最小值，然后计算平均值。
可以通过在分析图上点击右键 – “Set Granularity”（快捷键是Ctrl+G）来修改平均事务响应时间图的采样频率。

Average Load指的是在过去的1分钟的平均负载, 即在过去的1分钟处于就绪状态的平均进程数；如果这个数字大于CPU的个数，则至少有一个线程要等待CPU; 如果这个数除以CPU的数目，结果高于5的时候就表明系统在超负荷运转了

为了深入理解Average Load，我又查找了一些资料，其中下面的这个解释，个人认为还是不错的。

在Linux系统中，uptime、w、top等命令都会有系统平均负载load average的输出，那么什么是系统平均负载呢？
系统平均负载被定义为在特定时间间隔内运行队列中的平均进程树。如果一个进程满足以下条件则其就会位于运行队列中：
- 它没有在等待I/O操作的结果
- 它没有主动进入等待状态(也就是没有调用’wait’)
- 没有被停止(例如：等待终止)
例如：
[root@localhost ~]# uptime
7:51pm up 2 days, 5:43, 2 users, load average: 8.13, 5.90, 4.94
命令输出的最后内容表示在过去的1、5、15分钟内运行队列中的平均进程数量。
一般来说只要每个CPU的当前活动进程数不大于3那么系统的性能就是良好的，如果每个CPU的任务数大于5，那么就表示这台机器的性能有严重问题。对于上 面的例子来说，假设系统有两个CPU，那么其每个CPU的当前任务数为：8.13/2=4.065。这表示该系统的性能是可以接受的。

Average Load:上一分钟同时处于“就绪”状态的平均进程数
Collision Rate: 每秒钟在以太网上检测到的冲突数
Context Switches Rate: 每秒钟在进程或线程之间的切换次数
CPU Utilization: CPU 的使用时间百分比
Disk Rate: 磁盘传输速率
Incoming Packages Error rate: 接收以太网数据包时每秒钟接收到的错误数
Incoming Packages Rate:每秒钟传入的以太网数据包数
Interrupt Rate: 每秒内的设备中断数
Outgoing Packages Error Rate: 发送以太网数据包时每秒钟发送的错误数
Outgoing Packages Rate:每秒钟传出的以太网数据包数
Page-in Rate:每秒钟读入到物理内存中的页数
Page-out Rate:每秒钟写入页面文件和从物理内存中删除的页数
Paging Rate:每秒钟读入物理内存或写入页面文件中的页数
Swap-in Rate: 每秒交换到内存的进程数
Swap-out Rate: 每秒从内存交换出来的进程
System Mode CPU Utilization: 在系统模式下使用 CPU 的时间百分比
User Mode CPU Utilization:在用户模式下使用 CPU 的时间百分比

以下代码运行通过，放在vuser_init中即可
//定义tomcat内存使用情况的监视器事务；
lr_start_transaction(“monitor tomcat”);

//保存3个参数；
web_reg_save_param(“JVMFreeMemory”,
“LB=Free memory: “,
“RB= MB”,
“Ord=1″,
LAST);
web_reg_save_param(“JVMTotalMemory”,
“LB=Total memory: “,
“RB= MB”,
“Ord=1″,
LAST);

web_reg_save_param(“JVMMaxMemory”,
“LB=Max memory: “,
“RB= MB”,
“Ord=1″,
LAST);
//通过LR去访问tomcat监控页
web_set_user(“admin”,”123456″,”192.168.31.91″);

web_url(“status”,
“URL=http://192.168.31.91/manager/status”,
“Resource=0″,
“RecContentType=text/html”,
“Referer=”,
“Snapshot=t1.inf”,
“Mode=HTTP”,
LAST);

lr_end_transaction(“monitor tomcat”, LR_AUTO);

// Tomcat JVM metrics 使用lr_user_data_point（）添加数据到图表中去
lr_user_data_point(“Tomcat JVM Free memory”, atof(lr_eval_string(“{JVMFreeMemory}”)));
lr_user_data_point(“Tomcat JVM Total memory”, atof(lr_eval_string(“{JVMTotalMemory}”)));
lr_user_data_point(“Tomcat JVM Max memory”, atof(lr_eval_string(“{JVMMaxMemory}”)));

目前还存在的问题，如果并发太多，就无法监控到Tomcat的资源，请求都被拒绝掉了，还没有找到解决方案。。。

下面代码运行成功的前提：
负载机上安装了oracle的客户端，并且network\admin\tnsnames.ora文件中配置了数据库的连接，举个例子
lrtest =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.100)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = orcl)
)
)

一、连接oracle的代码放在vuser_init中，代码如下
#include “lrd.h”

static LRD_INIT_INFO InitInfo = {LRD_INIT_INFO_EYECAT};

static LRD_PRINT_ROW_TYPEDEF PrintRow24;

static LRD_DEFAULT_DB_VERSION DBTypeVersion[] =

{

{LRD_DBTYPE_NONE, LRD_DBVERSION_NONE}

};

static LRD_CONNECTION * Con1;

static LRD_CURSOR * Csr1;

vuser_init()
{
lrd_init(&InitInfo, DBTypeVersion);

lrd_open_connection(&Con1, LRD_DBTYPE_ORACLE, “用户名”, “密码”, “lrtest”, “”, 0, 0, 0);

}

二、sql语句放在Action中，Action中的代码如下：
Action()
{

double trans_time; //定义一个double型变量用来保存事务执行时间

lr_think_time(5);
lr_rendezvous(“SELECT”);

lr_start_transaction(“SELECT”);

lrd_open_cursor(&Csr1, Con1, 0);

lrd_stmt(Csr1,”SELECT * FROM 表名\n”, -1, 1, 1, 0);

lrd_exec(Csr1, 0, 0, 0, 0, 0);
//lrd_print(Csr1,PrintRow24)

lrd_close_cursor(&Csr1, 0);

lrd_commit(0, Con1, 0);

//trans_time=lr_get_transaction_duration( “SELECT” ); //获得该SQL的执行时间

//lr_output_message(“SELECT事务耗时 %f 秒”, trans_time); //输出该时间

lr_end_transaction(“SELECT”, LR_AUTO);

}

三、关闭数据库连接放在Vuser_end中，代码如下：
vuser_end()
{
lrd_close_connection(&Con1, 0, 0);

lrd_end(0);

return 0;
}

需要用到3个包
1. rsh-0.17-14.i386.rpm
（下载地址：http://rpm.pbone.net/index.php3/stat/4/idpl/2407867/com/rsh- 0.17-14.i386.rpm.html）
2. rsh-server-0.17-14.i386.rpm
（下载地址：http://rpm.pbone.net/index.php3/stat/4/idpl/2407868/com/rsh- server-0.17-14.i386.rpm.html）
3. rpc.rstatd-4.0.1.tar.gz
（下载地址：http://ncu.dl.sourceforge.net/project/rstatd/rstatd/4.0.1 /rpc.rstatd-4.0.1.tar.gz）

第一步：安装rsh，和rsh-server两个服务包
1. 卸载rsh
rpm –q rsh——查看版本号
rpm -e 查看到的版本——卸载该版本。
2. 安装
rpm –ivh rsh-0.17-14.i386.rpm rsh-server-0.17-14.i386.rpm

第二步：安装rstatd
tar -xzvf rpc.rstatd-4.0.1.tar.gz
./configure ——配置
make ——编译
make install ——安装
rpc.rstatd ——启动rstatd进程

第三步：修改/etc/xinetd.d/下的三个conf文件 rlogin ，rsh，rexec 这三个配置文件
打开这三个文件，将里面的disable = yes都改成 disable = no （disabled用在默认的{}中禁止服务）
或是把# default： off都设置成 on ，并把“#”去掉，这个的意思就是在xinetd启动的时候默认都启动上面的三个服务！

第四步：重启xinetd：
service xinetd reload 或者 /sbin/service xinetd rstart
（启动rstatd： rpc.rstatd）

第五步：查看rstatd是否启动：
rpcinfo –p
如果能看到：
100001 5 udp 618 rstatd
100001 3 udp 618 rstatd
100001 2 udp 618 rstatd
100001 1 udp 618 rstatd
就说明rstatd服务已经启动。

第六步：在LR的Controller中添加Unix Resources，就可以监视Linux了

group：多个脚本之间按照独立设置模式跑，各个脚本可以单独设置虚拟用户、运行时间等
scenario：多个脚本之间按照相同的模式跑，将总的虚拟用户数按照一定的比例分配给各个脚本

从51testing上闲逛的时候发现的，虽然现在没有遇到这些个问题，但还是有必要做个备份，以防以后遇到。

1．LoadRunner超时错误：在录制Web协议脚本回放时超时情况经常出现，产生错误的原因也有很多，解决的方法也不同。

　　错误现象1：Action.c(16): Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s)。

　　错误分析：对于HTTP协议，默认的超时时间是120秒（可以在LoadRunner中修改），客户端发送一个请求到服务器端，如果超过120秒服务器端还没有返回结果，则出现超时错误。

　　解决办法：首先在运行环境中对超时进行设置，默认的超时时间可以设置长一些，再设置多次迭代运行，如果还有超时现象，需要在“Runtime Setting”>“Internet Protocol：Preferences”>“Advanced”区域中设置一个“winlnet replay instead of sockets”选项，再回放是否成功。

　　错误现象2：Action.c(81):Continuing after Error -27498: Timed out while processing URL=http://172.18.20.70:7001/workflow/bjtel/leasedline/ querystat/ subOrderQuery.do

　　错误分析：这种错误常常是因为并发压力过大，服务器端太繁忙，无法及时响应客户端的请求而造成的，所以这个错误是正常现象，是压力过大造成的。

　　如果压力很小就出现这个问题，可能是脚本某个地方有错误，要仔细查看脚本，提示的错误信息会定位某个具体问题发生的位置。

　　解决办法：例如上面的错误现象问题定位在某个URL上，需要再次运行一下场景，同时在其他机器上访问此URL。如果不能访问或时间过长，可能是服务器或者此应用不能支撑如此之大的负载。分析一下服务器，最好对其性能进行优化。

　　如果再次运行场景后还有超时现象，就要在各种图形中分析一下原因，例如可以查看是否服务器、DNS、网络等方面存在问题。

　　最后，增加一下运行时的超时设置，在“Run-Time Settings”>“Internet Protocol:Preferences”中，单击“options”，增加“HTTP-request connect timeout” 或者“HTTP-request receive”的值。

2．LoadRunner脚本中出现乱码：在录制Web协议脚本时出现中文乱码，在回放脚本时会使回放停止在乱码位置，脚本无法运行。

　　错误现象：某个链接或者图片名称为中文乱码，脚本运行无法通过。

　　错误分析：脚本录制可能采用的是URL-based script方式，如果程序定义的字符集合采用的是国际标准，脚本就会出现乱码现象。

　　解决办法：重新录制脚本，在录制脚本前，打开录制选项配置对话框进行设置，在“Recording Options”的“Advanced”选项里先将“Surport Charset”选中，然后选中支持“UTF-8”的选项。

3．LoadRunner HTTP服务器状态代码：在录制Web协议脚本回放脚本的过程中，会出现HTTP服务器状态代码，例如常见的页面-404错误提示、-500错误提示。

　　错误现象1：-404 Not Found服务器没有找到与请求URI相符的资源，但还可以继续运行直到结束。

　　错误分析：此处与请求URI相符的资源在录制脚本时已经被提交过一次，回放时不可再重复提交同样的资源，而需要更改提交资源的内容，每次回放一次脚本都要改变提交的数据，保证模拟实际环境，造成一定的负载压力。

　　解决办法：在出现错误的位置进行脚本关联，在必要时插入相应的函数。

　　错误现象2：-500 Internal Server Error服务器内部错误，脚本运行停止。

　　错误分析：服务器碰到了意外情况，使其无法继续回应请求。

　　解决办法：出现此错误是致命的，说明问题很严重，需要从问题的出现位置进行检查，此时需要此程序的开发人员配合来解决，而且产生的原因根据实际情况来定，测试人员无法单独解决问题，而且应该尽快解决，以便于后面的测试。

4．LoadRunner请求无法找到：在录制Web协议脚本回放脚本的过程中，会出现请求无法找到的现象，而导致脚本运行停止。

　　错误现象：Action.c(41): Error -27979: Requested form not found [MsgId: MERR-27979]

　　Action.c(41): web_submit_form highest severity level was “ERROR”,0 body bytes, 0 header bytes [MsgId: MMSG-27178]”

　　这时在tree view中看不到此组件的相关URL。

　　错误分析：所选择的录制脚本模式不正确，通常情况下，基于浏览器的Web应用会使用“HTML-based script”模式来录制脚本；而没有基于浏览器的Web应用、Web应用中包含了与服务器进行交互的Java Applet、基于浏览器的应用中包含了向服务器进行通信的JavaScript/VBScript代码、基于浏览器的应用中使用HTTPS安全协议，这时则使用“URL-based script”模式进行录制。

　　解决办法：打开录制选项配置对话框进行设置，在“Recording Options”的“Internet Protocol”选项里的“Recording”中选择“Recording Level”为“HTML-based script”，单击“HTML Advanced”，选择“Script Type”为“A script containing explicit”。然后再选择使用“URL-based script”模式来录制脚本。

5．LoadRunner不执行检查方法：在录制Web协议脚本中添加了检查方法Web_find，但是在脚本回放的过程中并没有执行。

　　错误现象：在脚本中插入函数Web_find，在脚本中设置文本以及图像的检查点，但是在回放过程中并没有对设置的检查点进行检查，即Web_find失效。

　　错误分析：由于检查功能会消耗一定的资源，因此LoadRunner默认关闭了对文本以及图像的检查，所以在设置检查点后，需要开启检查功能。

　　解决办法：打开运行环境设置对话框进行设置，在“Run-time Settings”的“Internet Protocol”选项里的“Perference”中勾选“Check”下的“Enable Image and text check”选项。

6．LoadRunner回放Web Services协议脚本错误：LoadRunner 8.0版本在录制Web Services协议的脚本时正常，但在回放时会出现错误，提示停止脚本运行。

　　错误现象：利用LoadRunner 8.0版本来录制Web Services协议的脚本没有任何错误提示，回放脚本时会出现如下错误提示“Error：server returned an incorrectly formatted SOAP response”。

　　错误分析：出现此错误的原因是LoadRunner8.0在录制Web Services协议的脚本时存在一个缺陷：如果服务器的操作系统是中文的，VuGen会自动将WSDL文件的头改为<?xml version=”1.0″encoding=”zh_cn” ?>，所以才会有此错误提示。

　　解决办法：下载两个补丁，分别为“LR80WebServicesFPI_setup.exe”和“lrunner_web_ services_patch_1.exe”安装上即可。