用LoadRunner进行压力测试

LoadRunner工具介绍

LoadRunner是一种自动负载测试工具，它通过模拟用户实施并发负载、实时性能监测的方式来确认和查找问题，优化性能和加速应用系统的发布周期。

LoadRunner主要由虚拟用户发生器(VuGen)、压力控制器（Controller）、压力产生器（Load Generator）和结果分析工具(Analysis)组成，架构图如图1。

1.虚拟用户发生器(VuGen)实际上是一个集成开发环境，用于录制和编辑虚拟用户脚本的工具。

2.压力控制器（Controller）是一个框架程序和监控程序,负责将VuGen开发的脚本以多进程的方式在Load Generator机器上运行。

图1 LoadRunner工具架构图

3.压力产生器（Load Generator）是扮演产生负载的角色，根据脚本内容，产生实际的负载。

4.压力结果分析工具(Analysis)是一个数据分析工具, 用于测试后的结果分析。

5.用户确定要进行测试的业务,通过用户操作和VuGen的录制功能来记录并生成虚拟用户脚本。手工修改虚拟用户脚本,并确定脚本可以回放成功。在Controller中对场景进行配置,启动测试。

在测试过程中，Controller控制Load Generator对被测系统的加压方式和行为，同时负责搜集被测系统各个环节的性能数据，而各个Load Generator会记录最终用户的响应时间和脚本执行日志。

压力运行结束后，Load Generator将数据传送到Controller中，由Controller对测试结果进行汇总。测试人员借助Analysis对性能测试数据进行分析，进而确定瓶颈和调优方案。对系统进行调优，重复负载测试过程，直至符合系统性能要求。

压力测试的常见问题

问题1：信息系统的访问量急剧增长，当访问量达到一个阈值时，系统性能急剧下降，此时访问量与系统性能之间的关系是非线性的，这个阈值难以预测。

问题2：信息系统始终是处于变化中，不断的变化又会产生其他风险，IT人员缺乏对这些风险的预测能力。

问题3：业务应用是由许多事务构成，我们经常需要以事务为单元对系统性能进行监测。

比如，电商平台上，用户购买商品的整个操作过程就是一个事务。每个事务包含一连串的用户动作，虽然这些动作高度相关，但是这些动作关联在一起后，对性能的影响却难以量化。

问题4：信息系统种类多，系统性能受多种因素影响，包括软件代码效率、系统稳定性、服务器性能、网络性能等等，如何精确配置系统，使系统性能满足业务需求，粗略估计的方法显然存在很大风险。

下面我们以模拟的办公自动化（OA）系统为环境，以LoadRunner为工具，介绍压力测试的方法。

测试内容及流程方法

测试内容

测试内容主要是：服务器是否能承受现有的系统负载；业务的极限负载。

图2 录制结果

规划负载测试

1.系统环境

为了便于演示和分析，整个测试环境均在一台服务器上完成：利用虚拟机在实体服务器上搭建OA系统；在实体服务器上安装LoadRunner；网络环境为虚拟的星形结构，OA系统为中心，对外提供服务，模拟用户采用百兆局域网访问OA系统。

图3 场景控制

2.系统负载

系统主要提供基于网页的OA服务，最大用户数50左右。

3.创建测试脚本

LoadRunner测试脚本可以通过行为录制的方式进行创建。录制过程中，LoadRunner将会记录所有用户操作和系统响应，记录的结果是脚本，通过对脚本的编辑可以实现批量化、个性化的参数修改。例如，在用户登录过程中，通过脚本读取参数，能实现自动以不同的用户身份登录系统，这样就能使模拟行为更加真实，如图2所示。

4.创建负载测试场景

LoadRunner通过场景来模拟用户的实际环境。在场景中，可以添加多个脚本，我们添加刚才录制的脚本后开始创建场景，如图3。

在图中左上角为“场景组”编辑区，可以在这里对负载进行调整。按照本部门服务器的负载情况，我们添加50个虚拟用户。

用户数是比较简单的场景设置，除此之外，我们还可以设置更为复杂的场景，使测试场景和实际环境尽可能一致。

比如，可以安排向系统施加负载的时间（因为用户不会正好同时登录或退出系统）；使用不同类型的浏览器 （例如360、谷歌、搜狗等浏览器）来浏览网页；使用不同的网络连接（例如局域网、光纤或E1专线），这些复杂的模拟都可以在场景实现。

5.运行负载测试

设置好场景后，可以开始负载测试。根据场景设置，每15秒新增两个用户在线，逐渐增加负载，LoadRunner将记录下系统的各个指标，如图4。

运行结束后，总共产生了89个失败的事务，1149个系统错误，下面就对这些错误进行分析。

图4 负载测试运行结束

图5 用户-错误组合图

图6 用户-资源组合图

6.分析测试结果

在运行过程中，出现错误。为了找到错误原因，我们利用结果分析功能对测试进行分析。系统出现错误是在负载不断增加的情况下产生的，首先看系统在何时出现错误，通过截取组合图来查找原因，图5是每秒错误数与用户数的关系组合图。

图5中每秒错误数曲线在5:20时开始出现错误（此时用户数也在40左右），到6:24时错误达到最高峰。

通过图5可以初步判断，OA系统用户数的极限基本在40左右。超过40用户数，系统将会产生大量错误。

虽然得出系统极限用户数，但这还不足以为改善系统提供参考。我们希望可以定位系统出现错误的原因，找到系统瓶颈。

先看服务器性能在测试中的表现，查看是否因为服务器资源不够，导致负载增加后，出现错误。图6是用户数与系统资源的组合图。

从图形来看，在服务器资源中的几十项指标中，随着负载的增长，并没有指标变得特别差或者波动较大。因此，可以确定在50用户数的负载下，服务器的性能表现并没有出现瓶颈，产生错误的原因不是OA服务器系统资源的不足。

再看一下产生的错误能否给我们提供一些参考信息。LoadRunner的错误报告提示了以下三种错误信息：

Action.c(130):错误-27796:连接服务器“1080 端口”失败:“[10061]连接被拒绝”

Action.c(4):错 误-27792:将数据传输到网络失败: “[10054]对等端已重置连接”

Action.c(4):错 误-27791:服务器已过早关闭连接

从错误信息可以看到，错误信息都是关于网络连接的，大量的连接请求被拒绝、重置和关闭。从连接错误这条线索，我们考虑另一个因素对系统性能的影响：网络性能。网络性能的好坏一般用吞吐量来衡量，在服务器资源没有明显变差的前提下，吞吐量基本上可以代表网络状况，图7为用户数与吞吐量的组合图。

图7 用户-吞吐量组合图

可以看到，用户数在40以前，吞吐量与用户数基本是线性相关的，但是当用户数到达40左右时，系统吞吐量开始变得不稳定。吞吐量表征的是网络性能，如果随着时间的推移和用户数目的增加，吞吐量不断增加，说明带宽够用；如果随着用户数目的增加，吞吐量达到网络性能极限后，并没有继续增长，而是出现较大波动，某些情况下反而出现吞吐量极低的情况，这主要是因为网络性能达到极限，出现网络拥塞后，网络性能大幅下降引起。对于系统来说，网络出现拥塞，用户发起的许多请求就会超时，产生大量错误。

模拟环境下，OA服务器和LoadRunner测试环境均在同一实体终端下，测试过程中的数据收发都是通过实体终端的网卡完成，所以容易造成网络拥塞。笔者认为如果将LoadRunner测试环境安装在另外一台实体终端，将较好的解决网络拥塞的问题。

7.验证

通过以上的原因分析，我们推断系统整体的性能瓶颈在于网络资源不足。为了验证这个推断，我们将LoadRunner测试环境安装到局域网内的另一台实体终端上进行测试，测试结果证实了笔者的猜想。

总结

通过以上简单的测试过程，我们就容易得出两个结论：

结论1：模拟环境下OA系统的极限用户数为同时40用户在线操作。

结论2：OA系统性能的瓶颈在于网络性能。具体来说，根据错误提示可以知道，如果要提升性能，首先应该提高网络带宽。

以上案例是一个比较典型的压力测试。在我们的信息系统中，还有很多类似的系统在业务化之前基本没有经过专业的、定量化的测评，都是凭借我们长期工作中的经验进行评估，系统上线运行后风险较大。

我们研究利用LoadRunner进行系统压力测试和评估，寻找性能瓶颈、预测性能极限，这在信息化建设中是一项基础性的工作，做好这项工作将使信息系统的开发和运营更加科学和规范。