8描述性统计与性能结果分析.docx
《8描述性统计与性能结果分析.docx》由会员分享，可在线阅读，更多相关《8描述性统计与性能结果分析.docx（20页珍藏版）》请在冰豆网上搜索。
8描述性统计与性能结果分析
LoadRunner没有告诉你的之一
LoadRunner中的90%响应时间是什么意思？
这个值在进行性能分析时有什么作用？
本文争取用最简洁的文字来解答这个问题，并引申出描述性统计”方法在性能测试结果分析
中的应用。
为什么要有90%用户响应时间？
因为在评估一次测试的结果时，仅仅有平均事务响应时间是不够的。
为什么这么说？
你可以试着想想，是否平均事务响应时间满足了性能需求就表示系统的性能已经满足了绝大多数用户的要求？
假如有两组测试结果，响应时间分别是｛1,3,5,10,16｝和｛5,6,7,8,9｝，它们的平均值都是7,你认为哪次测试的结果更理想？
假如有一次测试，总共有100个请求被响应，其中最小响应时间为0.02秒,最大响应时间为110秒,平均事务响应时间为4.7秒,你会不会想到最小和最大响应时间如此大的偏差是否会导致平均值本身并不可信？
为了解答上面的疑问，我们先来看一张表:
CmdID
NUM
MEAN
STDOEV
MIN
50th
ZDlh
Wth
90th
95th
MAX
HomePage
99
453
IV
333
406
457
487
577
799
1105
100
294
□05
22G
25S
291
348
4D8
4超
B44
在上面这个表中包含了几个不同的列，其含义如下:
CmdID测试时被请求的页面
NUM响应成功的请求数量
MEAN所有成功的请求的响应时间的平均值
STDDEV
标准差（这个值的作用将在下一篇文章中重点介绍）
MIN
响应时间的最小值
50th（60/70/80/90/95th）如果把响应时间从小到大顺序排序，那
么50%的请求的响应时间在这个范围之内。
后面的60/70/80/90/95th也是同
样的含义
MAX响应时间的最大值
我想看完了上面的这个表和各列的解释，不用多说大家也可以明白我的意思了。
我把结论性的东西整理一下：
1.90%用户响应时间在LoadRunner中是可以设置的，你可以改为80%或95％；
2.对于这个表，LoadRunner中是没有直接提供的，你可以把LR中的原始数据导出到Excel中，并使用Excel中的PERCENTILES数很简单的算出不同百分比用户请求的响应时间分布情况；
3.从上面的表中来看，对于HomePage来说，平均事务响应时间（MEAN）
只同70%用户响应时间相一致。
也就是说假如我们确定HomePage的响
应时间应该在5秒内，那么从平均事务响应时间来看是满足的，但是实际上有10-20%的用户请求的响应时间是大于这个值的；对于Page1也
是一样，假如我们确定对于Page1的请求应该在3秒内得到响应，虽然平均事务响应时间是满足要求的，但是实际上有20-30%的用户请求的响应时间是超过了我们的要求的；
4.你可以在95th之后继续添加96/97/98/99/99.9/99.99th，并利用Excel的图表功能画一条曲线，来更加清晰表现出系统响应时间的分布情况。
这时候你也许会发现，那个最大值的出现几率只不过是千分之一甚至万分之一，而且99%的用户请求的响应时间都是在性能需求所定义的范围之内的；
5.如果你想使用这种方法来评估系统的性能，一个推荐的做法是尽可能让你的测试场景运行的时间长一些，因为当你获得的测试数据越多，这个响应时间的分布曲线就越接近真实情况；
6.在确定性能需求时，你可以用平均事务响应时间来衡量系统的性能，也可以用90%或95%用户响应时间来作为度量标准，它们并不冲突。
实际上，在定义某些系统的性能需求时，一定范围内的请求失败也是可以被接受的；
7.上面提到的这些内容其实是与工具无关的，只要你可以得到原始的
响应时间记录，无论是使用LoadRunner还是JMeter或者OpenSTA你都可以用这些方法和思路来评估你的系统的性能。
LoadRunner没有告诉你的之二
数据统计分析的思路与分析结果的展示方式是同样重要的，有了好的分析思路，但是却不懂
得如何更好的展示分析结果和数据来印证自己的分析，就像一个人满腹经纶却不知该如何一
展雄才一图胜千言，所以这次我会用两张图表来说明“描述性统计”在性能测试结果分析中
的其他应用。
http:
//jackeicnhlogscom
在这张图中，我们继续使用了上一篇文章一一《描述性统计与结果分析》一文中的方法，对
响应时间的分布情况来进行分析。
上面这张图所使用的数据是通过对
G首页进行测试得来的，在测试中分别使用10/25/50/75/100几个不同级别的并发用户数量。
通过这张图表，我们可以通过横向比较和纵向比较，更清晰的了解到被测应用在不同级别的负载下的响应能力。
http:
Ablogscom
这张图所使用的数据与第一张图一样，但是我们使用了另外一个视角来对数据进行展示。
表
中最左侧的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时，系统几乎已经无法为
任何用户提供响应了。
这张图表也同样可以用于对不同负载下事务的成功、失败比例的比较分析。
LoadRunner没有告诉你的之四
本文是《LoadRunner没有告诉你的》系列文章的第四篇，在这篇短文中，我将尽可能用简洁清晰的文字写下我对“性能”的看法，并澄清几个容易混淆的概念，帮助大家更好的理解
“性能”的含义。
如何评价性能的优劣：
用户视角vs.系统视角
对于最终用户（End-User）来说，评价系统的性能好坏只有一个字一一“快”。
最终用户并不需
要关心系统当前的状态一一即使系统这时正在处理着成千上万的请求，对于用户来说，由他
所发出的这个请求是他唯一需要关心的，系统对用户请求的响应速度决定了用户对系统性能
的评价。
而对于系统的运营商和开发商来说，期望的是能够让尽可能多的用户在任意时刻都拥有最好的体验，这就要确保系统能够在同一时间内处理更多的用户请求。
正如在《理发店模型》一
文中所描述的：
系统的负载（并发用户数）与吞吐量（每秒事务数）、响应时间以及资源利
用率（包括软硬件资源）之间存在着一个“此消彼长”的关系。
因此，从系统的运营商和开发商的角度来看，所谓的“性能”是一个整体的概念，是系统的负载与吞吐量、可接受的响应时间以及资源利用率之间的平衡。
换句话说，“好的性能”意味着更大的最佳并发用户数（TheOptimumNumberofConcurrent
Users）和最大并发用户数（TheMaximumNumberofConcurrentUsers）。
有关“最佳/最大并发用户数”的概念请参见《理发店模型》一文。
另外，从系统的视角来看，所需要关注的还包括三个与“性能”有关的属性：
可靠性（Reliability），可伸缩性（Scalability）和可恢复性（Recoverability）我将会在本系列文章的第五篇“无
处不在的性能测试”中专门讨论这三个属性的含义和相关的实践经验。
响应时间
Ciimnt
口*
Internet
N1・
wet）Server
Al
N2
Database
Server
A2
€2
Jr
p
A3
■
►
亠N3
1
q
上面这张图引自段念兄的一份讲义，不过我略作了些修改。
从图中我们可以清楚的看到一个
请求的响应时间是由几部分时间组成的，包括
C1:
用户请求发出前在客户端需要完成的预处理所需要的时间；
C2:
客户端收到服务器返回的响应后，对数据进行处理并呈现所需要的时间；
A1:
Web/AppServer对请求进行处理所需要的时间；
A2:
DBServer对请求进行处理所需的时间；
A3:
Web/AppServer对DBServer返回的结果进行处理所需的时间；
N1：
请求由客户端发出并达到Web/AppServer所需要的时间；
N2:
如果需要进行数据库相关的操作，由Web/AppServer将请求发送至DBServer所需要
的时间；
N3:
DBServer完成处理并将结果返回Web/AppServer所需的时间；
N4:
Web/AppServer完成处理并将结果返回给客户端所需的时间；
从用户的角度来看，响应时间=（C1+C2）+（A1+A2+A3）+（N1+N2+N3+N4；但是从系统的角度来
看，响应时间只包括（A1+A2+A3）+（N1+N2+N3+N4）。
在理解了响应时间的组成之后，可以帮助我们通过对响应时间的分析来更好的识别和定位系
统的性能瓶颈。
吞吐量vs.吞吐量
在不同的测试工具中，对于吞吐量（Throughput）会有不同的解释。
例如，在LoadRunner中，这个指标是以字节数为单位来衡量网络吞吐量的，而在JMeter中则是以事务数/秒为单位来衡量系统的响应能力的。
不过在大多数英文的性能测试方面的书籍或资料中，吞吐量的定义使用的是后者。
并发用户数工每秒请求数
这是两个容易让初学者混淆的概念。
简单说，当你在性能测试工具或者脚本中设置了100并发用户数后，并不能期望着一定会有每秒100个请求发给服务器。
事实上，对于一个虚拟用户来说，每秒发出多少请求只跟服务器返回响应的速度有关。
如果虚拟用户在0.5秒内就收到了响应，那么它会立即发出第二个请求；而如果要一直等待3秒才能得到响应，它将会一直等到收到响应后才发出第二个请求。
也就是说，并发用户数的设置只是保证服务器在任一时刻都有100个请求需要处理，而并不一定是保证每秒中发送100个请求给服务器。
所以，只有当响应时间恰好是1秒时，并发用户数才会等于每秒请求数；否则，每秒请求数可能大于并发用户数或小于并发用户数。
LoadRunner没有告诉你的之五
提到性能测试，相信大家可以在网上找到很多种不同的定义、解释以及分类方法。
不过归根结底，在大多数情况下，我们所要做的性能测试的目的是“观察系统在一个给定的环境和场景中的性能表现是否与预期目标一致，评判系统是否存在性能缺陷，并根据测试结果识别性能瓶颈，改善系统性能”。
本文是《LoadRunner没有告诉你的》系列的第五篇，在这篇文章中，我希望可以跟大家一起来探讨“如何将性能测试应用到软件开发过程的各个阶段中，如何通过尽早的开展性能测试来规避因为性能缺陷导致的损失”。
因此，本文的结构也将依据软件开发过程的不同阶段来组织。
另外，建议您在阅读本文前先阅读本系列文章的第三篇《理发店模型》和第四篇《理解性能》。
需求阶段
我们不可能将一辆设计载重为0.75吨的皮卡改装成载重15吨的大型卡车，如果你面对的正是这样的问题，那么恐怕你只能重做一辆，而且客户不会为你之前那辆付钱。
对于一个已经完成的应用系统来说也是如此。
如果我们在系统结构确定之前就能够了解到系统的将要面对的压力，用户的使用习惯和使用频度，我们就可以更早也更有效的提前解决或预防可能发生的性能缺陷，也将会极大的减少后期返工和反复调优所带来的工作量。
如果我们预期到系统的容量将会不断的增长，我们还可以给出相应的解决方案来低成本的解决这类问题，就像上面那辆皮卡，也许你可以有办法把20辆皮卡捆在一起，或者把15吨的东西分由20辆来运。
分析设计阶段
系统性能的优化并不是要等待整个系统全部集成后才能开始的，早在分析设计阶段，我们就可以开始考虑系统的技术架构和数据库部分的优化。
数据库通常位于整个系统的最底层，如果直到系统上线前才发现因为数据库设计不合理而导致性能极差，通常使用任何一种方法来优化都已经于事无补了。
要避免这类问题，最常见的做法是在数据库结构确定后，通过工具或脚本向数据库中注入大量的数据，并模拟各种业务的数据库操作。
根据对数据库性能的观察和分析，对数据库表结构和索引进行调整以优化数据库性能。
在系统的技术架构方面，要明白先进的技术并不是解决问题的唯一方法，过于强调技术的作用反而会将你带入歧途。
例如：
某些业务虽然经常面临着巨大的压力，并且业务本身的复杂性决定了通过算法的优化来提高系统的性能收效甚微。
但是我们知道用户对于该业务的实时性要求并不高，并且返回结果对于不同用户来说是相同的。
那么我们完全可以考虑将每次请求都动态生成返回结果的方式改为每次用户请求都返回一个定期更新的静态页面。
另外，所谓“先进技术”通常都会在带来某一方面改进的同时带来另一方面的问题，未经试验就盲目的在系统中加入各种流行元素未必是最好的选择。
例如ORM可以提供一些方便，但是它生成的SQL是未经优化的，有时甚至比人工编写的SQL效率更低。
最后，要知道不同厂家的设备性能是不同的，而且不同的硬件设备搭载不同的操作系统、数据库、中间件以及应用服务器，表现出来的性能也是不同的。
如果有足够的资源，应当考虑提前进行软硬件平台的对比选型；如果没有足够的资源，可以考虑通过一些专业的组织或网站来获取或购买相关的评估报告。
编码阶段
一片树叶在哪里最难被发现？
——当这片树叶落在一堆树叶里面的时候。
如果你只是在系统测试完成后才开始性能测试，那么即使发现系统存在性能缺陷，并且已经有了几个可供怀疑的对象，但是当一段因为使用了不当的算法而导致执行效率很低的代码藏身于一个庞大的系统中时，找出它是非常困难的。
避免这种情况出现的方法是尽早开始核心业务代码的性能测试，重点集中在对算法和实现方法的优化上。
另外，及早开始的测试也可以帮你更容易找到内存泄漏的问题。
测试阶段
产品终于交到我们手上了，搭建测试环境，设计测试场景，执行测试，找到系统的最佳并发用户数和最大并发用户数，将系统进行分类，评判系统的性能表现是否满足需求中定义的目标如果有需求的话A_A
如果发现系统的性能表现与预期目标相去甚远，则需要根据执行测试过程中收集到的数据来分析和识别性能瓶颈，优化系统性能。
在这个阶段还有很多值得我们深入思考和讨论的东西，在本系列后续的文章中，我们将会更多的关注这一部分的内容。
维护阶段
维护阶段通常遇到的问题是需要在实验室中模拟客户环境，重现在客户那里发现的缺陷并修复缺陷。
相比功能缺陷，性能缺陷与某一具体环境和场景的关联更加密切，所以在测试前需要检查生产环境中各服务器的资源利用率、系统访问日志、应用服务器的日志、数据库的日志。
如果客户使用了专门的系统来监测各个服务器的软硬件资源使用情况的话，检查该系统
是否记录下了软硬件资源的异常或者警告。
与性能测试相关的其他测试
可靠性测试（ReliabilityTesting）对于一个运营商级的系统来说，能够保证提供7X24
的连续稳定的服务是非常重要的。
当然，你可以通过一些“高可用性（HighAvailability）”技
术方案来增强系统的可靠性，但是对于系统本身的可靠性测试是不能被忽略的。
常用的测试方法是使用一定的负载长时间向服务器加压，并观察随着加压时间的延长，响应
时间、吞吐量以及资源利用率的变化。
要注意的是，所使用的负载应当是系统的最佳并并发用户数，而不是最大并发用户数。
可伸缩性测试（ScalabilityTesting）对于一个系统来说，在一个给定的环境下，它的最佳并发用户数和最大并发用户数是客观存在的，但是系统所面临的压力却有可能随上线时间的延长而增大。
例如，一个在线购物站点，注册用户数量不断增多，访问站点查询商品信息和购买商品的人也不断的增多，我们应该用一种什么样的方案，在不影响系统继续为用户提供服务的前提下来实现系统的扩容？
一种常用的方案是使用负载均衡（LoadBalanee）和集群（Cluster）技术。
但是在我们为客
户提供这种方案之前，需要先自己进行测试，保证该技术的有效性——我们是否真的可以通过简单的增加服务器数据和修改某些参数配置，就能够使得系统的容量得到线性的增长？
可恢复性测试（ReeoverabilityTesting）虽然我们已经可以准确的估算出系统上线后将
要面对的压力，并且可以保证系统的最佳并发用户数和最大并发用户数是足以应对这些压力
9.11事件发生后，AOL
的，但是这个世界上总是有些事情上我们所无法预料到的一一例如的网站访问量在短时间内增长到了平时的数十倍。
我们无法保证系统可以在任何情况下都能为用户正确无误的提供服务，但是我们需要确保当
意外过去后，系统可以恢复到正常的状态，并继续后来的用户提供服务一一就像从未发生过
任何事情一样。
如果要实现“可恢复性测试”，我们可以借助于测试工具或脚本来逐渐的增大并发用户数，直至并发用户数已经超过了系统所能承受的最大并发用户数，并导致软硬件资源利用率饱和，
响应时间无限延长，大量的请求因为超过响应时间要求或无法获得响应而失败；之后，我们
逐渐的减少并发用户数，并观察资源利用率、响应时间、吞吐量以及交易成功率的变化是否与预期目标一致。
当然，这一切的前提是在系统负载达到峰值前，Server一直在顽强的挣扎着而没有down掉
Elapsedtime
性能测试，并非网络应用专属
软件的性能和性能测试都是伴随着网络应用的兴起而逐渐被重视起来的，但是软件性能和性
能测试却并非网络应用的专属名词，因为单机版的应用同样需要考虑性能问题。
下面举几个
简单的例子来方便大家的理解：
1.当使用Word来编辑一个500多页，并包含了丰富图表、图片和各种格式、样式信息的文
档时，是否每次对大段的文字或表格的修改、删除或重新排版，都要等待系统花几秒钟的时
间进行处理？
2.当在ExceI中使用嵌套的统计和数学函数对几万行记录进行统计分析时，是否每次都要两
三分钟才能看到结果？
3.杀毒软件是否每次都要花费两个小时才能完成一次对所有的分区的扫描？
4.是否每次在手机的通讯簿中根据姓名搜索某个人的联系方式都要三四秒钟才有响应？
如果大家有兴趣，也可以通过Google搜索到更多的有关单机应用性能测试的资料。
点击这里了解整个系列的创作进度，查看文章目录，或浏览已经完成的文章。
LoadRunner没有告诉你的之六
本文是《LoadRunner没有告诉你的》系列的第六篇，我将继续保持“无废话”的原则，用尽可能简洁、明确的语句来表述我对性能测试的看法和经验。
在这篇文章中，我们要讨论的是如何获取“有效的”性能需求。
一个实际的例子
为了便于大家的理解，我们先来看一个性能需求的例子，让大家有一个感性的认识，本文后面的讨论也会再次提到这个例子。
这是一个证券行业系统中某个业务的“实际需求”——实际上是我根据通过网络搜集到的数据杜撰出来的，不过看起来像是真实的A_A
系统总容量达到日委托6000万笔，成交9000万笔
系统处理速度每秒7300笔，峰值处理能力达到每秒10000笔
实际股东帐号数3000万
这个例子中已经包括几个明确的需求：
最佳并发用户数需求：
每秒7300笔最大并发用户数需求：
峰值处理能力达到每秒10000笔基础数据容量：
实际股东帐号数3000万
业务数据容量：
日委托6000万笔，成交9000万笔——可以根据这个推算出每周、每月、每年系统容量的增长模型
什么是“有效的”性能需求？
要想获得有效的性能需求，就要先了解什么样的需求是“有效的”。
有效的性能需求应该符合以下三个条件。
1.明确的数字，而不是模糊的语句。
结合上面的例子来看，相信这个应该不难理解。
但是有的时候有了数字未必就不模糊。
例如常见的一种需求是“系统需要支持5000用户”，或者“最大在线用户数为8000”。
这些有数字的需求仍然不够明确，因为还需要考虑区分系统中不同业务模块的负载，以及区分在线用户和并发用户的区别。
关于这方面的内容，在下面两篇文章中的留言内容中有精彩的讨论：
2.有凭有据，合理，有实际意义。
通常来说，性能需求要么由客户提出，要么由开发方提出。
对于第一种情况，要保证需求是合理的，有现实意义的，不能由着客户使劲往高处说，要让客户明白性能是有成本的。
对于第二种情况，性能需求不能简单的来源于项目组成员、PM或者测试工程师的估计或者猜测，要保证性能需求的提出是有根据的，所使用的数据和计算公式是有出处的——本文后面的部分会介绍获得可用的数据和计算公式的方法。
3.相关人员达成一致。
这一点非常关键。
如果相关人不能对性能需求达成一致，可能测了也白测——特别是在客户没有提出明确的性能需求而由开发方提出时。
这里要注意“相关人员”的识别，通常项目型的项目的需要与客户方的项目经理或负责人进行确认，产品型的项目需要与直属领导或者市场部进行确认。
如果实在不知道该找谁确认，那就把这个责任交给你的直属领导；如果你就是领导了，那这领导也白当了A_A
如何获得有效的性能需求
上面提到了“有效的”性能需求的一个例子和三个条件，下面来我们将看到有哪些途径可以帮助我们获得相关的数据——这些方法我在实际的工作中都用过，并且已经被证实是可
行的。
这几种方法由易到难排列如下：
1.客户方提出
这是最理想的一种方式，通常电信、金融、保险、证券以及一些其他运营商级系统的客户——特别是国外的客户都会提出比较明确的性能需求。
根据客户以往的业务情况来分析客户的业务量以及每年、每
升级会员 