描述性统计与性能结果分析——《LoadRunner 没有告诉你的》

LoadRunner中的90%响应时间是什么意思?这个值在进行性能分析时有什么作用?本文争取用最简洁的文字来解答这个问题,并引申出“描述性统计”方法在性能测试结果分析中的应用。

为什么要有90%用户响应时间?因为在评估一次测试的结果时,仅仅有平均事务响应时间是不够的。为什么这么说?你可以试着想想,是否平均事务响应时间满足了性能需求就表示系统的性能已经满足了绝大多数用户的要求?

假如有两组测试结果,响应时间分别是{1,3,5,10,16}和{5,6,7,8,9},它们的平均值都是7,你认为哪次测试的结果更理想?

假如有一次测试,总共有100个请求被响应,其中最小响应时间为0.02秒,最大响应时间为110秒,平均事务响应时间为4.7秒,你会不会想到最小和最大响应时间如此大的偏差是否会导致平均值本身并不可信?

为了解答上面的疑问,我们先来看一张表:

 

 

在上面这个表中包含了几个不同的列,其含义如下:

 

CmdID  测试时被请求的页面

NUM     响应成功的请求数量

MEAN   所有成功的请求的响应时间的平均值

STD DEV     标准差(这个值的作用将在下一篇文章中重点介绍)

MIN             响应时间的最小值

50 th(60/70/80/90/95 th)        如果把响应时间从小到大顺序排序,那么50%的请求的响应时间在这个范围之内。后面的60/70/80/90/95 th也是同样的含义

MAX     响应时间的最大值

 

我想看完了上面的这个表和各列的解释,不用多说大家也可以明白我的意思了。我把结论性的东西整理一下:

1.     90%用户响应时间在LoadRunner中是可以设置的,你可以改为80%或95%;

2.     对于这个表,LoadRunner中是没有直接提供的,你可以把LR中的原始数据导出到Excel中,并使用Excel中的PERCENTILE函数很简单的算出不同百分比用户请求的响应时间分布情况;

3.     从上面的表中来看,对于Home Page来说,平均事务响应时间(MEAN)只同70%用户响应时间相一致。也就是说假如我们确定Home Page的响应时间应该在5秒内,那么从平均事务响应时间来看是满足的,但是实际上有10-20%的用户请求的响应时间是大于这个值的;对于Page 1也是一样,假如我们确定对于Page 1的请求应该在3秒内得到响应,虽然平均事务响应时间是满足要求的,但是实际上有20-30%的用户请求的响应时间是超过了我们的要求的;

4.     你可以在95 th之后继续添加96/ 97/ 98/ 99/ 99.9/ 99.99 th,并利用Excel的图表功能画一条曲线,来更加清晰表现出系统响应时间的分布情况。这时候你也许会发现,那个最大值的出现几率只不过是千分之一甚至万分之一,而且99%的用户请求的响应时间都是在性能需求所定义的范围之内的;

5.     如果你想使用这种方法来评估系统的性能,一个推荐的做法是尽可能让你的测试场景运行的时间长一些,因为当你获得的测试数据越多,这个响应时间的分布曲线就越接近真实情况;

6.     在确定性能需求时,你可以用平均事务响应时间来衡量系统的性能,也可以用90%或95%用户响应时间来作为度量标准,它们并不冲突。实际上,在定义某些系统的性能需求时,一定范围内的请求失败也是可以被接受的;

7.     上面提到的这些内容其实是与工具无关的,只要你可以得到原始的响应时间记录,无论是使用LoadRunner还是JMeter或者OpenSTA,你都可以用这些方法和思路来评估你的系统的性能。

 

事实上,在性能测试领域中还有更多的东西是目前的商业测试工具或者开源测试工具都没有专门讲述的——换句话说,性能测试仅仅有工具是不够的。我们还需要更多其他领域的知识,例如数学和统计学,来帮助我们更好的分析性能数据,找到隐藏在那些数据之下的真相。

数据统计分析的思路与分析结果的展示方式是同样重要的,有了好的分析思路,但是却不懂得如何更好的展示分析结果和数据来印证自己的分析,就像一个人满腹经纶却不知该如何一展雄才

^_^

一图胜千言,所以这次我会用两张图表来说明“描述性统计”在性能测试结果分析中的其他应用。

在这张图中,我们继续使用了上一篇文章——《描述性统计与结果分析》一文中的方法,对响应时间的分布情况来进行分析。上面这张图所使用的数据是通过对

Google.com首页进行测试得来的,在测试中分别使用10/25/50/75/100几个不同级别的并发用户数量。通过这张图表,我们可以通过横向比较和纵向比较,更清晰的了解到被测应用在不同级别的负载下的响应能力。

这张图所使用的数据与第一张图一样,但是我们使用了另外一个视角来对数据进行展示。表中最左侧的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%的事务的响应时间处在危险的临界值,而且有相当数量的事务的响应时间超过了用户可以容忍的限度;随着并发用户数量的进一步增加,超过用户容忍限度的事务越来越多,当并发用户数到达75时,系统几乎已经无法为任何用户提供响应了。

这张图表也同样可以用于对不同负载下事务的成功、失败比例的比较分析。

 

Note:上面两个图表中的数据,主要通过Excel中提供的FREQUENCY,AVERAGE,MAX,MIN和PERCENTILE几个统计函数获得,具体的使用方法请参考Excel帮助手册。

====================================分割线================================

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-11-02 05:54:45

描述性统计与性能结果分析——《LoadRunner 没有告诉你的》的相关文章

list 、set 、map 粗浅性能对比分析

 list .set .map 粗浅性能对比分析   不知道有多少同学和我一样,工作五年了还没有仔细看过list.set的源码,一直停留在老师教导的:"LinkedList插入性能比ArrayList好,LinkedList顺序遍历性能比ArrayList好"的世界里.可是真是如此么?本文很"肤浅"的对比和分析了几种常用的集合,"高手"可以就此打住不必往下阅读了... 本文分开介绍了List.Map.Set: (测试环境:win7.jdk.4G.

理解性能 ——《LoadRunner 没有告诉你的》之四

理解性能 --<LoadRunner 没有告诉你的>之四 本文是<LoadRunner没有告诉你的>系列文章的第四篇,在这篇短文中,我将尽可能用简洁清晰的文字写下我对"性能"的看法,并澄清几个容易混淆的概念,帮助大家更好的理解"性能"的含义. 如何评价性能的优劣: 用户视角 vs. 系统视角 对于最终用户(End-User)来说,评价系统的性能好坏只有一个字--"快".最终用户并不需要关心系统当前的状态--即使系统这时正在

DRDS实例性能评估分析

一.DRDS实例性能评估分析目标 通常我们在分布式数据库选项过程中会对DRDS实例进行性能评估分析,我认为主要包含以下3个目的: 1.评估DRDS性能,判断DRDS是否满足预期的性能需求 2.获取DRDS性能容量及各负载条件下性能表现,为容量规划提供参考依据 3.定位诊断DRDS性能瓶颈及原因并调整优化   二.性能评估分析主要性能指标   1.资源指标: CPU 利用率:DRDS 服务节点的CPU资源平均利用率 网络输入流量:DRDS 服务节点的网络输入流量的总和 网络输出流量:DRDS 服务

网站流量统计与网站访问分析的概念辨析

访问|概念|流量|统计 网站流量统计的基本含义: 网站流量统计,是指对网站访问的相关指标进行统计,常用的网站流量统计指标包括三类:(1)网站流量指标,如在一定统计周期那网站的独立用户数量.总用户数量.网页浏览数量.每个用户的页面浏览数量等 :(2)用户行为指标,如用户来源网站.用户所使用的搜索引擎及其关键词.在不同时段的访问量情况等:(3)用户浏览网站的方式,如用户上网设备类型.用户浏览器的名称和版本.访问者电脑分辨率显示模式等. 网站访问分析的基本含义: 所谓网站访问分析(有时也使用"网站流量

用win7性能监视器分析电脑为什么卡

平常我们电脑卡的时候,第一个想到的通常是360安全卫士各种清理.而使用电脑比较久的人,是通过任务管理器来清理一些比较占内存的程序,但是如果你能通过使用win7自带的性能检测器,那么你将看得更直观. 1 我们可以通过在运行里面输入"perfmon"来进入性能检测器. 2 性能管理器的功能是很强大的.里面有CPU.内存.磁盘.网络等功能. 在这里我们可以详细的看到哪些东西最占网络,那么最占内存.以后当我们启动这些软件的时候,自己心里清楚该怎么做. 3 在性能管理器里面,小编最喜欢的是它的日

php中file_get_contents与curl性能比较分析_php技巧

本文实例讲述了php中file_get_contents与curl性能比较分析.分享给大家供大家参考.具体如下: 在php中如果不仔细的去分析性能会发现file_get_contents与curl两个同很多共同点的,他们都可以采集文件打开文件,但是如果仔细一对比会发现很多不同点,下面我们一起来看看file_get_contents与curl区别. PHP中fopen,file_get_contents,curl函数的区别: 1.fopen /file_get_contents 每次请求都会重新做

Docker最新安全性能调整分析

本文讲的是Docker最新安全性能调整分析,[编者的话]作者通过对Docker的最新安全更新的深入分析与探索,总结了四条有关Docker安全更新的调整建议,包括调整能力.调整SELinux的标签.多级安全模式.调整命名空间. 自我发表前两篇有关Docker安全系列的文章之后,至今已有一段时间.本文更新了自那以后有关Docker的新增内容,并且介绍了全新功能,其中涵盖了与上游Docker的合并过程. 调整能力 在前面的文章中,我介绍了基于Linux功能的容器分离. 借助Linux功能,你可以分离根

一条insert语句导致的性能问题分析(二)

今天对之前描述的问题一条insert语句导致的性能问题分析(一) 进行了进一步的补充. 有一条insert语句的主要性能瓶颈在于insert子句中的查询语句,查询中的主要资源消耗在于对两个表进行了多次关联 语句主要的结构如下: insert into xxxxx   (select * from TEST_vip_new minus select * from TEST_vip_new_bak         ) a left join TEST_vip_new_bak b         on

无所不在的性能测试——《LoadRunner 没有告诉你的》之五

无所不在的性能测试--<LoadRunner 没有告诉你的>之五 提到性能测试,相信大家可以在网上找到很多种不同的定义.解释以及分类方法.不过归根结底,在大多数情况下,我们所要做的性能测试的目的是"观察系统在一个给定的环境和场景中的性能表现是否与预期目标一致,评判系统是否存在性能缺陷,并根据测试结果识别性能瓶颈,改善系统性能". 本文是<LoadRunner没有告诉你的>系列的第五篇,在这篇文章中,我希望可以跟大家一起来探讨"如何将性能测试应用到软件开