loadrunner结果分析论文.docVIP

Loadrunner 结果分析论文 指导老师：高小雷 作者：闵光辉 学校：东莞理工学院 学号：200841402210 班级：08计算机科学与技术2班 实验日期：2011-6-19 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三个时间点吞吐量最大，到后面基本处于稳定状态，这不难看出是由于点击数引起的。 5、Transaction Summary 结果分析如下： 有该图不难看出，该系统处于正常运行状态。 6、Vuser Summary 结果分析如下： 由该图不难看出：虚拟用户通过的占96%，失败的占4%。所以，从整体上来看，大部分用户运行正常。 7、Error Statistics 结果分析如下： 从上图不难看出:错误数据只有1个，所以也可以看出系统基本运行正常。 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、Transacti