loadrunner没有告诉你

1、LoadRunner没有告诉你的之描述性统计与性能结果分析Posted on 2006-11-11 22:59 Jackei阅读(13393)评论(54)编辑收藏网摘所属分类: 04.软件性能测试版权声明：本文可以被转载，但是在未经本人许可前，不得用于任何商业用途或其他以盈 利为目的的用途。本人保留对本文的一切权利。如需转载，请在转载是保留此版权声明，并保证 本文的完整性。也请转贴者理解创作的辛劳，尊重作者的劳动成果。作者：陈雷(Jackei)由K箱： HYPERLINK mailto:jackeichan jackeichanBlog： HYPERLINK LoadRunner中的90%响应

2、时间是什么意思？这个值在进行性能分析时有什么作用？本文争 取用最简洁的文字来解答这个问题，并引申出“描述性统计”方法在性能测试结果分析中的应用。为什么要有90%用户响应时间？因为在评估一次测试的结果时，仅仅有平均事务响应时间 是不够的。为什么这么说？你可以试着想想，是否平均事务响应时间满足了性能需求就表示系统 的性能已经满足了绝大多数用户的要求？假如有两组测试结果，响应时间分别是1，3，5，10，16和5, 6，7，8，9，它们的 平均值都是7,你认为哪次测试的结果更理想？假如有一次测试，总共有100个请求被响应，其中最小响应时间为0.02秒，最大响应时间 为110秒，平均事务响应时间为4.7

3、秒，你会不会想到最小和最大响应时间如此大的偏差是否会 导致平均值本身并不可信？为了解答上面的疑问，我们先来看一张表:CmdIDNUMMEANSTD DEVMIN50th701 h80th90th95thMAXHome Page994 531.473 334 D84 57 875,777.9911 05Pagel1002.940.852 262592 913 484.084658 44在上面这个表中包含了几个不同的列，其含义如下:CmdID测试时被请求的页面NUM响应成功的请求数量MEAN所有成功的请求的响应时间的平均值STD DEV标准差（这个值的作用将在下一篇文章中重点介绍）MIN响应时间的

4、最小值50 th(60/70/80/90/95 th)如果把响应时间从小到大顺序排序，那么50%的请求的响应时间在这个范围之内。后面的60/70/80/90/95 th也是同样的含义MAX 响应时间的最大值我想看完了上面的这个表和各列的解释，不用多说大家也可以明白我的意思了。我把结论 性的东西整理一下：90%用户响应时间在LoadRunner中是可以设置的，你可以改为80%或95%；对于这个表,LoadRunner中是没有直接提供的，你可以把LR中的原始数据导出到Excel 中，并使用Excel中的PERCENTILE函数很简单的算出不同百分比用户请求的响应时间 分布情况；从上面的表中来看，对

5、于Home Page来说，平均事务响应时间（MEAN）只同70%用户响 应时间相一致。也就是说假如我们确定Home Page的响应时间应该在5秒内，那么从平 均事务响应时间来看是满足的，但是实际上有10-20%的用户请求的响应时间是大于这 个值的；对于Page 1也是一样，假如我们确定对于Page 1的请求应该在3秒内得到 响应，虽然平均事务响应时间是满足要求的，但是实际上有20-30%的用户请求的响应 时间是超过了我们的要求的；你可以在95 th之后继续添加96/ 97/ 98/ 99/ 99.9/ 99.99 th，并利用Excel的图 表功能画一条曲线，来更加清晰表现出系统响应时间的分布

6、情况。这时候你也许会发现， 那个最大值的出现几率只不过是千分之一甚至万分之一，而且99%的用户请求的响应 时间都是在性能需求所定义的范围之内的;如果你想使用这种方法来评估系统的性能，一个推荐的做法是尽可能让你的测试场景 运行的时间长一些，因为当你获得的测试数据越多，这个响应时间的分布曲线就越接近 真实情况；在确定性能需求时，你可以用平均事务响应时间来衡量系统的性能，也可以用90%或 95%用户响应时间来作为度量标准，它们并不冲突。实际上，在定义某些系统的性能需 求时，一定范围内的请求失败也是可以被接受的；上面提到的这些内容其实是与工具无关的，只要你可以得到原始的响应时间记录，无 论是使用Loa

7、dRunner还是JMeter或者OpenSTA，你都可以用这些方法和思路来评估你 的系统的性能。事实上，在性能测试领域中还有更多的东西是目前的商业测试工具或者开源测试工具都没 有专门讲述的一一换句话说，性能测试仅仅有工具是不够的。我们还需要更多其他领域的知识， 例如数学和统计学，来帮助我们更好的分析性能数据，找到隐藏在那些数据之下的真相。欢迎各位同行高手灌水拍砖A_A数据统计分析的思路与分析结果的展示方式是同样重要的，有了好的分析思路，但是却不 懂得如何更好的展示分析结果和数据来印证自己的分析，就像一个人满腹经纶却不知该如何一展 雄才一图胜千言，所以这次我会用两张图表来说明“描述性统计”在性

8、能测试结果分析中的其 他应用。(SWJulu-f-tu#IJoCL0ua:3DOQO250002DOQO2406.29 2CG2 20724SBT 490T5D577Z70. WEnurw口 SIJum 白VE：口 F5umi:fe： LOOazers3104403B034043063JL.TO514753J911132.011045131911&495.91B33179452KL0.OZB633K66gjjj STI 13969 1荒T8 5093461T313CC51L2O1.21414016T35囹河Z30336O4TZ927Z. 23E63& 33ZZS. 5

9、355411 瑜m.s能iza. i35 L眺1159441941T3Z1763559 HYPERLINK http:/jackei.Gnblogs.conn http:/jackei.Gnblogs.conn在这张图中，我们继续使用了上一篇文章一一描述性统计与结果分析一文中的方法，对响应时间的分布情况来进行分析。上面这张图所使用的数据是通过对G首页进行测试得来的，在测试中分别使用10/25/50/75/100几个不同级别的并发用户数 量。通过这张图表，我们可以通过横向比较和纵向比较，更清晰的了解到被测应用在不同级别的负载下的 响应能力。这张图所使用的数据与第一张图一样，但是我们使用了另外一个

10、视角来对数据进行展示。表中最左侧的2000/5000/10000/50000的单位是毫秒，分别表示了在整个测试过程中，响应时间 在0-2000毫秒范围内的事务数量占成功的事务总数的百分比，响应时间在2001-5000毫秒范围 内的事务数量占成功的事务总数的百分比，响应时间在5001-10000毫秒范围内的事务数量占成 功的事务总数的百分比，以及响应时间在10001-50000毫秒范围内的事务数量占成功的事务总数 的百分比。这几个时间范围的确定是参考了业内比较通行的“ 2-5-10原则”一一当然你也可以为自己 的测试制定其他标准，只要得到企业内的承认就可以。所谓的“ 2-5-10原则”，简单说，就是 当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时， 会感觉系统的响应速度还可以；当用户在5-10秒以内得到响应时，会感觉系统的响应速度很慢， 但是还可以接受；而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟透了，或者认为 系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。那么从上面的图表中可以看到，当并发用户数量为10时，超过95%的用户都可以在5秒内 得到响应；当并发用户数量达到25时，已经有80%的事务的响应时间处在危险的临界值，而且 有相当数量的事务的响应时间超过了用户可以容忍的限度；随着并发用户数量的进一步增加，超 过