如何分析loadrunner性能测试结果

在Controller执行的测试场景结束后，首先要做的是判断采集到的结果数据是否真实有效。多数性能测试场景都需要迭代地进行测试，因此很多测试结果本身就不能反映真正的问题，而深入分析这样的结果纯属浪费时间。主要探讨如何针对有效的测试结果数据进行分析。

判断测试结果是否有效，通常按下面的步骤进行：

第一步：在整个测试场景的执行过程中，测试环境是否正常。如果在测试过程中出现过异常，那么这样得出的结果往往不准确，无须进行分析。

例如，在测试执行过程中，测试机的CPU利用率经常达到100%、测试环境的网络不稳定、一些系统参数配置不正确等等，这样得出的测试结果没有必要进行分析，应该重新设置测试场景或调整测试环境，再次执行测试。

第二步：测试场景的设置是否正确、合理。测试场景的设置是否正确对测试结果有很大的影响。因此，当测试出现异常时，我们要对场景设置进行分析。

一些新手在使用Controller执行测试时，可能会同时在一台PC上加载全部虚拟用户——例如同时加载1000个虚拟用户，如果客户端来不及处理，就 会有很多虚拟用户因不能初始化而失败。失败的根本原因不是被测试的应用服务器不能处理，而是压力根本没有传输过去。正确的做法是增加更多的 Generator或逐步加压，使测试场景运行起来。

第三步：测试结果是否直接暴露出系统的一些问题。对测试场景的整个执行过程，没有必要对压力下系统运行正常的结果进行分析，因为这样的结果不能反映出系统 的性能问题，应该进一步调整场景（比如增大压力）进行测试。在测试过程中使系统表现不正常的测试场景生成的结果则要进行深入分析。实际上，分析能够反映性 能问题的测试结果才是性能分析阶段的主要工作。

测试结果直接暴露系统存在性能问题的情形很多，例如在测试过程中一些用户事务响应时间过长、系统支持的最大并发用户数过低、系统的应用服务器CPU利用率 过高或内存不足等。对这类测试结果，性能测试人员需要借助Analysis对其进行深入分析，以发现一些潜在的性能问题。

性能分析的基本原则

确定测试结果有效之后，接下来就要开始对测试数据进行深入的挖掘了。面对测试工具产生的纷繁复杂的原始测试数据，如何来进行分析呢？一个普遍遵循的原则是“由外而内，由表及里，层层深入”，如图5-1所示。

图5-1  性能分析原则示意图

对于一个应用系统，性能开始出现下降的最直接表象就是系统的响应时间变长。于是，系统响应时间成为分析性能的起点。性能分析的原则如图5-1所示，首先应 该从原始测试数据中查看系统响应时间，判断它是否满足用户性能的期望。如果不能满足，则说明系统的性能出现了问题。发现系统存在问题后，就要判断系统在哪 个环节出现了瓶颈。

现在的IT系统架构极其复杂，任何一个环节出现瓶颈，都会导致系统出现性能问题。要准确地判断瓶颈在什么地方，的确是一个棘手的问题。不过，任何复杂的系统都分为网络和服务器两部分。因此要考察的第二个问题就是：系统的瓶颈是出现在网络环节，还是服务器环节？

如图5-2所示，用户从客户端发起的请求数据包经过网络，传递到应用服务器，最后到达数据库服务器，服务器处理完毕后按原路返回到客户端。在这个处理过程中，可以把整个时间分为两段：一段是Tn，即网络的响应时间；一段是Ts，即服务器的响应时间，包括应用服务器和数据库服务器的响应时间。对比Tn和Ts，就很容易知道系统在哪些环节的响应时间比例较大。

图5-2  客户交易分解图

只要判断出系统的瓶颈是出现在网络或是服务器段，就可以层层推进对相应环节的组件响应时间进行深入分析，直到最后找到造成性能问题的根本原因。

借助LoadRunner的分析组件Analysis，很容易按照“由外而内，由表及里，层层深入”的原则进行分析，快速将问题定位。例如从图5-3中可以直接看出瓶颈出现在网络上。

图5-3  客户请求第一个Buffer的分解示例

性能分析任重而道远

看了前面的内容，也许很多人会以为性能分析非常容易，借助工具即可完成，但实则不然。即使有了正确的测试结果，也不一定能对系统的性能问题进行正确定位。 例如，服务器的内存不够可能会引起较大的磁盘I/O，进而导致CPU利用率居高不下，其根本原因可能是程序内部存在内存泄漏，而不是内存瓶颈。这类问题不 但要靠经验，更要靠对系统的深入了解。

不难看出，性能测试是难度较大的一项工作，绝不是一蹴而就的事情。根据作者的经验，最好的办法是把性能分析贯穿于性能测试过程的始末，所有人员都应该给予高度关注。

实际上，性能测试分析从测试场景执行时就开始了，而不是仅仅在测试结束后才进行的。例如，在测试执行过程中可以借助分析数据库，观察事务实时响应时间来发现一些问题。

除了这些通用的方法外，性能测试分析人员还应该在测试设计、执行、分析等各阶段把工作做透，只有这样才能把性能测试工作做好。