loadrunner结果分析论文(标准版)

Loadrunner 结果分析论文
指导老师：高小雷
作者：闵光辉
学校：东莞理工学院
班级：08计算机科学与技术2班
邮箱：mingh168@
Loadrunner性能测试的目的：
自动性能测试是一项规范，它利用有关产品、人员和过程的信息来减少应用程
序、升级程序或修补程序部署中的风险。

自动性能测试的核心原理是通过将生产
时的工作量应用于预部署系统来衡量系统性能和最终用户体验。

构造严密的性能
测试可回答如下问题：
➤应用程序是否能够很快地响应用户的要求？
➤应用程序是否能处理预期的用户负载并具有盈余能力？
➤应用程序是否能处理业务所需的事务数量？
➤在预期和非预期的用户负载下，应用程序是否稳定？
➤是否能确保用户在真正使用软件时获得积极的体验？
通过回答以上问题，自动性能测试可以量化更改业务指标所产生的影响。

进而可
以说明部署的风险。

有效的自动性能测试过程将有助于您做出更明智的发行决
策，并防止系统出现故障和解决可用性问题。

LoadRunner 包含下列组件：
➤虚拟用户生成器用于捕获最终用户业务流程和创建自动性能测试脚本（也称为虚拟用户脚本）。

➤Controller 用于组织、驱动、管理和监控负载测试。

➤负载生成器用于通过运行虚拟用户生成负载。

➤Analysis 有助于您查看、分析和比较性能结果。

➤Launcher 为访问所有LoadRunner 组件的统一界面。

负载测试流程：
负载测试通常由五个阶段组成：计划、脚本创建、场景定义、场景执行和结果
分析。

计划负载测试：定义性能测试要求，例如并发用户的数量、典型业务流程和所需
响应时间。

创建Vuser 脚本：将最终用户活动捕获到自动脚本中。

定义场景：使用LoadRunner Controller 设置负载测试环境。

运行场景：通过LoadRunner Controller 驱动、管理和监控负载测试。

分析结果：使用LoadRunner Analysis 创建图和报告并评估性能。

Loadrunner测试结果分析如下：
1、Analysis Summary 结果及分析如下：
此次测试我用了30个用户，但有1个failed，5个error。

所以实际参与测试的虚拟用户总共有24个。

其中，总的吞吐量为3448691bytes，平均吞吐量为12965bytes，总的请求量为720，平均每秒请求量为2.707。

从该图可以看出，该系统存在一定的问题，在失败和错误的数量来看占到了总虚拟用户的20%，该比例还是挺大的，所以从这个方面可以看出在系统登录方面还存在一定问题。

2、Running Vusers结果及分析如下：
通过上面图形结果可知，在刚开始虚拟用户为0，30秒多时突然达到24个用户访问，一直到4：17秒将为16个用户，到4：25秒24个用户全部访问结束。

3、Hits perSecond结果及分析如下：
该图为每秒点击次数，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请数。

通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。

通过对查看“每秒点击次数”，可以判断系统是否稳定。

系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。

由上图不难看出：分别在0s、40s、1：12s三个时间点点击数最大，到后面基本处于稳定状态。

4、Througput结果分析如下：
该图和上面第三个图恰好相识，由上图不难看出：分别在0s、40s、1：12s三个时间点吞吐量最大，到后面基本处于稳定状态，这不难看出是由于点击数引起的。

5、Transaction Summary 结果分析如下：
6、Vuser Summary 结果分析如下：
由该图不难看出：虚拟用户通过的占96%，失败的占4%。

所以，从整体上来看，大部分用户运行正常。

7、Error Statistics 结果分析如下：
8、Error per Second结果分析如下：
从上图不难看出：在刚开始时出现错误，在8秒以后无错误出现，从而也反映系统运行基本正常。

9、Average Transaction Response Time结果分析如下：
10、Transaction per Second结果分析如下：
11、Total Transaction per Second结果分析如下：
由上图不难看出：失败的6个用户没有响应，而正常用户分别在32s、1：35、2：00、4：00、4：25时有响应，其他时间没有响应。

12、Transaction Performance Summary结果分析如下：
13、Transaction Response Time结果分析如下：
从上图不难看出：响应时间排序如下：Action_Transaction>付款>订票>Vuser_init_Transaction>登陆>选择航班> Vuser_end_Transaction。

14、Transaction Response Time结果分析如下：
该图和第13个图功能基本差不多，但通过该图可以看出该服务器性能是否在可以接受的范围内。

15、HTTP Responses per Second 结果分析如下：
该图显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其他各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。

通过该图不难看出：其和Hit per Second以及Throughput图形基本一致，所以可以判断系统运行基本稳定。

16、Pages Download per Second结果分析如下：
该图显示场景或会话步骤运行的每一秒内从服务器下载的网页数。

使用此图可依据下载的页数来计算Vuser生成的负载量。

和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。

但是吞吐量考虑的各个资源极其大小（例，每个GIF 文件的大小、每个网页的大小）。

而每秒下载页面数只考虑页面数。

从上图不难看出：平均每秒的页面下载量为一个页面。

17、Connection 结果分析如下：
该图显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。

从该图可以看出，在前两分钟里连接数为48，从2：00到3：52里连接数为24，在3：52到4：16里连接数为48，在4：16到4：30里连接数为32个。

18、Page Component Breakdown结果分析如下：
该图显示选定网页的页面组件随时间变化的细分图。

通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。

该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。

19、Page Download Time Breakdown结果分析如下：
该图显示每个页面组件下载时间的细分，可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。

“页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。

从该图不难看出：其平均时间不到1秒，所以确定在网页下载期间事务响应时间缓慢是由网络错误引起的。

20、Time to First Buffer Breakdown 结果分析如下：
该图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。

如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有关。

网络时间：定义为第一个HTTP请求那一刻开始，直到确认为止所经过的平均时间。

服务器时间：定义为从收到初始HTTP请求确认开始，直到成功收到来自Web服务器的一次缓冲为止所经过的平均时间。

从该图不难看出：其时间最长的就是1秒多一点，平均不到1秒，所以可以看出产生的问题与服务器有关而与网络无关。

21、综述
通过以上20个图形结果分析可以大概知道，该系统在登陆时还是存在一定的问题的，在失败和错误的数量来看占到了总虚拟用户的20%，该比例还是挺大的，所以从这个方面可以看出在系统登录方面还存在一定问题。

但总体来看，系统运行过程中基本正常，所以该系统还是比较稳定的。

同时，也说明了该应用程序能够很快地响应用户的要求，能处理预期的用户负载并具有盈余能力，能处理业务所需的事务数量，在预期和非预期的用户负载
下，应用程序是稳定的，用户在真正使用软件时能够极的体验。