只需4步，LoadRunner轻松实现大负载测试！省时省力

敏捷的技术时代需要测试开发者在提高产品质量的同时，能够缩短发布时间和精简工作流程。研发人员们现在正在短时间内自己完成端到端的周期，并不断发布新的修复和功能。

测试开发人员节省时间的方式之一是尽可能多的重复使用现有的脚本。这节省了创建新脚本的时间，并且还实现了自动化。

通常情况下，你可以通过很多可用的工具来对一个应用软件进行测试并可以得到有关性能级别和临界点等方面的报告。像大多数工具一样，你要先退出你所运行的东西并对测试做彻底的准备。我们今天就来聊一聊一个常用工具LoadRunner如何在大负载下进行测试？

首先，什么是负载测试？

负载测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试，例如，访问一个页面的响应时间规定不超过1秒，负载测试就是测试在响应时间为1秒时，系统所能承受的最大并发访问用户的数量。

负载测试的目标是确定并保证系统在超出最大预期工作量的情况下仍能正常运行，还能评估系统的性能特征。

下面介绍一下关于负载测试的几个基本概念：

吞吐率： 服务器并发处理能力的量化描述（单位reqs/s）,单位时间内处理的请求数。

并发连接数： 某一个时间点允许最大的请求数量，这个常用来衡量系统的并发处理请求的能力，应该区分与下面的并发用户数。

并发用户数： 一个用户可能会产生多个并发连接，例如IE8目前支持6个并发连接。

用户请求平均时间： 大量用户请求从发起到接收到处理结果的一个平均时间，在web页面默认不超过3秒是最佳的用户体念。

服务器平均处理请求时间： 处理完成一个请求所用的平均时间，这个指标可用来衡量业务逻辑复杂度和机器的性能指标。

再来了解下，什么是LoadRunner？

LoadRunner是一款适用于多种软件体系架构的负载测试工具，从用户关注的响应时间、吞吐量，并发用户数和性能计数器等方面来衡量系统的性能表现，辅助用户进行系统性能优化。

原理：LoadRunner通过模拟成千上万用户实施并发负载及实时性能监测的方式来确认和查找问题，优化性能和加速应用系统的发布周期。

组成：LoadRunner主要包括三个前台功能组件，分别为VuGen（虚拟用户脚本生成器）、Controller（测试控制器）和Analysis（结果分析器）。系统会自动调用后台功能组件LG（负载生成器）和Proxy（用户代理）来完成性能测试工作。

如何使用LoadRunner实现大负载测试？

第一步：配置系统参数

大并发用户的情况下，会出现如下问题：

1)当采用netstat命令时，看到很多Socket处于“WAIT”状态

2)负载增大时连接失败

3)mmdrv的句柄数 随着虚拟用户的运行而增加

4)当建立连接时出现"No buffer space available"错误信息

解决方法

编辑以下注册表项：

1.为了避免出现“No Buffer Space Available”的错误，需要进行如下配置：
1）修改注册表：
* 设置“HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Par
ameters\TcpTimedWaitDelay”为 30
* 设置“HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Par
ameters\MaxUserPort”为 65534
* 在“HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session
Manager\Sub Systems\Windows”设置SharedSection 为 4096 
2）通过在每个脚本的开头添加如下函数来设置“SHUTDOWN”模式为"ABRUPT"
web_set_sockets_option(“SHUTDOWN_MODE”,”ABRUPT”)

第二步：配置LR

1)脚本运行时设置

消息处理时勾选"send message only when error occurs"

禁用snapshot on error

"define each step as a transaction"取消勾选

取消"simulate browser cache"勾选, 勾选“simulate new user on each iteration”和它的子选项

2)将脚本中web_url函数中的"Mode=HTML"默认方式改为"Mode=HTTP",这将减小LG机器上的压力(不解析HTML)

3)将在controller的diagnostics->configuration中，禁止web page breakdown

4)在Controller通过Tools > Options > Run-Time Settings限制同一时间在所有LG上初始化虚拟用户的数值，设置会被每台LG获得，这样做的目的是为了避免在脚本执行的初始阶段LG系统资源的过度利用.

5)限制controller在运行时存储的错误数.通过修改wlrun.ini中的[output]项来实现:
• FlagLimitOutputMessages=1
• MaxNumberOfOutputMessages=<errors count> (default is 10,000)

6)在Controller通过Tools>Options>Monitors修改monitor的采样率，这将减小测试运行时Controller的CPU利用率，如下图所示：

7)修改wlrun7.ini中的ExportMessagesToFile=1重定向输出信息到.txt文件而不是到MDB文件

此外：关闭Controller和LG上的防病毒,防间谍软件,关于运行在以上电脑上不要的Windows服务；在Controller不要运行虚拟用户；不要频繁打开Error/Output窗口，因为这将增加额外Controller上额外的数据库连接数这些都是对进行成功的大负载测试的有益的建议。

第三步：修改脚本

1)在负载测试时，保证Controller和Generator的网络通信非常重要，大量的信息（error message,output message）大并发负载测试有着很大的负面影响

如以下两例

把脚本中所与打印信息的脚本去掉.如下面的代码每次迭代都会调用一次,对大量并发用户的运行产生负面的影响.

Controller处理所有虚拟用户的信息,这样会大大降低Controller的性能. 如下是类似的代码:

这些语句都仅仅应该出现在脚本调试时而不应该出现在负载测试时的脚本中，在正式的负载测试前，注释掉这些语句。

2)去掉脚本中所有的sleep()的调用,用lr_think_time()来代替.lr_think_time给LR让出控制,即LR能够在Vuser休眠的时候去做其他有用的事情.不要去掉lr_think_time:使用该函数能更准确的模拟负载,对LG产生相对小的压力

3)web_reg_save_param和web_reg_find()函数:
在 web_reg_save_param() 中添加“Notfound=empty” 参数.
在 web_reg_find() 添加 "Savecount=some_parameter_name". 如果你想知道它是否成功可以使用atoi(lr_eval_string("{some_paramater_name }"))来衡量.

第四步：设置组策略

大负载测试时会有以下情况发生：

●产生很多错误，数据量大于1GB

●假如每秒产生1000条左右错误的话，Controller的行为将很难预测

●压力测试产生很多运行数据

这些问题可以通过设置一个合理的组策略避免，以下举一个例子说明

场景为1000个虚拟用户，用一个Group运行

这时把这个Group分为两个Group：

G1-〉100 Vusers

G2-〉900 Vusers

这两个组可以跟原始的组产生一样的负载,对于G2在组命令行中添加如下参数:
-disable_data -disable_messages
_disable_data : 让这个组不发送任何信息,不发送任何online信息,不写任何offline信息.
_disable_message: 让这个组不给Controller发送任何信息(错误,日志)
注意:使用上面的命令行选项会使该LG不给congtroller发送online和offline信息.这样这个组上的虚拟用户的分析数据就收集不到了.

总结：

通过一段时间的学习发现，结合LR自带的使用手册，以及在网上找的N多资料，多看学习视频，然后多动手操作。慢慢的LR的一些操作步骤就会做的，所谓熟能生巧就是这回事情，至于分析结果这块所涉及的东西很多，这个要靠长期的经验的积累和学习。坚持做做多学多问，就很收获良多。加油！