基准测试性能测试的知识.docx
《基准测试性能测试的知识.docx》由会员分享，可在线阅读，更多相关《基准测试性能测试的知识.docx（43页珍藏版）》请在冰豆网上搜索。
基准测试性能测试的知识
什么是基准测试？
基准测试（benchmarking）是一种测量和评估软件性能指标的活动。
你可以在某个时候通过基准测试建立一个已知的性能水平（称为基准线），当系统的软硬件环境发生变化之后再进行一次基准测试以确定那些变化对性能的影响。
这是基准测试最常见的用途。
其他用途包括测定某种负载水平下的性能极限、管理系统或环境的变化、发现可能导致性能问题的条件，等等。
基准测试的具体做法是：
在系统上运行一系列测试程序并把性能计数器的结果保存起来。
这些结构称为“性能指标”。
性能指标通常都保存或归档，并在系统环境的描述中进行注解。
比如说，有经验的数据库专业人员会把基准测试的结果以及当时的系统配置和环境一起存入他们的档案。
这可以让他们对系统过去和现在的性能表现进行对照比较，确认系统或环境的所有变化。
基准测试通常都是些功能测试，即测试系统的某个功能是否达到了预期的要求。
有些性能测试工具可以对系统几乎所有的方面（从最常见的操作到最复杂的操作，从小负载到中等负载到大负载）进行测试。
大部分程序员只在系统发生了奇怪的事情时才考虑进行基准测试，但我认为定期进行基准测试，尤其是在重大事件（比如系统或环境发生变化）之前和之后进行基准测试更有意义。
一定要首先进行一次基准测试以创建基准线。
如果没有基准线作为参照物，在事件发生之后进行的基准测试是不会对你有多大帮助的。
1、优秀基准测试的指导原则
在进行基准测试的时候，有许多好的实践方法。
在这一节里，我将向大家介绍几个我认为对大家最有帮助的基准测试原则。
首先，应该牢记“事前快照”和“事后快照”的概念。
不要等到你对服务器做出修改之后才想起应该进行一次基准测试并把测试结果与你在六个月前建立的基准线进行对比。
六个月的时间会发生许多事情！
你应该在做出修改之前进行一次测试，做出修改，然后再对系统进行一次基准测试。
这可以让你对三组性能指标进行对比：
系统的预期性能、它在修改前的实测性能以及它在修改后的实测性能。
你可以发现所发生的事情让你的改变多少会明显一些。
比如说，假设你的基准测试有一项是度量查询时间。
你在六个月前为某个特定的测试查询建立的基准线需要花费4.25秒才能完成。
现在，你决定修改受测表的某个索引。
你在修改之前进行的基准测试得到的结果是15.5秒，而你在修改之后进行的基准测试得到的结果是4.5秒。
如果你没有拍摄事前快照，就不会知道你的修改让系统的性能有了很大的提高。
说不定还会以为你的修改降低了查询的速度--你也许会因此撤消这次修改，结果返回到执行速度慢的查询。
虽然这是一个假想的例子，但我希望大家能够从中注意到以下几点。
首先，如果你是在对某个系统的数据检索性能执行基准测试，而这个系统的数据量会随着时间的推移而增长，你必须更频繁地运行你的基准测试工具才能准确地把握数据量的增长对系统性能的影响。
在刚才的例子里，你应该把有关性能指标（比如数据负载量）在事前的测量值当作系统的“正常”指标。
其次，必须保证你的测试对你测量的东西有效。
如果你在对某个表的查询性能进行基准测试，你得到的测试结果只限于应用程序级别，不足以从一般意义上预测系统的性能。
一定要把应用程序级别的基准与全局性的性能指标区分开来，这样才能保证不会得出错误的结论。
另外一个与事前概念和事后概念有关的好的实践方法是，在活动（负载量相对稳定）的有限时间内尽可能多做几次基准测试，这是为了保证你的测试结果不会受到局部活动（比如临时出现的进程或高资源占用任务）的影响。
我发现重复进行几十次同样的基准测试可以把各次测试结果的平均值作为最终的性能指标值。
有许多技巧可以得到这些统计结果。
有条件的话，你甚至可以使用一个统计包或是你喜欢的适用于统计的电子表格应用程序来得出基本的统计数字。
注解：
有些基准测试工具有自己的统计分析包，但MySQLBenchmarkSuite没有。
我认为最有用的建议是每次只修改一个地方。
一次修改多个地方并不是不可以，但这样你就不能期望从基准测试结果里得出什么有意义的结论。
经常会发生这样的事：
你修改了6个地方，其中之一产生的负面影响掩盖了另外几个的正面效果，剩下的一两个对性能没有任何影响。
只有每次修改一个地方，你才能准确地判断出它对系统性能的影响是负面的、正面的还是没有影响。
还有，只要有可能，就应该使用实际数据来进行基准测试。
人工生成的测试数据怎么说也会有一些规律可循，那样得到的测试结果往往不能反映实际情况，某些特定的功能（比如边界值和范围检查等）可能永远也得不到测试。
如果你的数据变化很频繁，你应该选择某个时刻为它们“拍摄”一张快照，然后使用这张快照来进行每一次测试。
不过，这么做虽然能够保证使用真实的数据来测试性能，可是随着数据量的增长也许无法测试出系统性能的下降。
最后，在解读基准测试结果和管理预期目标时，一定要让你的目标有现实意义。
如果你想改善系统在某种特定条件下的性能，在确定目标前首先要把已知的后果弄清楚。
比如说，如果你想知道把网络接口的传输速度提高100倍对系统性能会产生哪些影响，就必须先弄清楚你的服务器将不能按照比现在快100倍的速度发送和接收数据。
在这类场合中，你必须综合考虑硬件的性价比和硬件可能带来的性能改善。
换句话说，你的服务器的执行速度应当提高几个百分点，这样就为你省了钱（或说增加了收入）。
如果在做过仔细评估之后预计你的网络性能只要提高10%就可以做到收支平衡甚至赢利，那就把这个数字作为你的目标好了。
如果基准测试结果表明你得到了这么大（或更好）的改善，就去找老板谈谈加薪的事吧；如果基准测试结果表明你没有得到这么大的改善，去建议老板把新硬件退回去（也可以顺便谈谈加薪的事，因为你让他省钱了）。
不管是哪种情况，你的报告都有充分的依据，即你的基准测试结果。
2、对数据库系统进行基准测试
基准测试在很多领域都非常重要。
但基准测试与数据库服务器到底有什么关系呢？
答案包括很多方面。
对数据库服务器进行基准测试可以在许多不同的层次上进行。
最常见的是针对数据库模式的改动而进行的基准测试。
专门针对某个表的基准测试比较少见（虽然你可以这么做）。
人们更感兴趣的是在改变了数据库的结构之后，其性能会受到什么样的影响。
人们的这种关心在刚开始使用一个新的应用程序或一个新的数据库时表现得尤为明显。
此时，你可以设计好几种数据库模式并填充数据，然后编写一些基准测试程序来模仿所推荐的系统。
嘿，这也是一种测试驱动的开发行为！
通过创建多个数据库模式并进行基准测试，甚至可能会多次重复这些改动，你很快就可以确定哪套模式最适合你设计的应用。
有时候，对数据库系统进行基准测试还有一些特殊的目的。
比如说，你想知道数据库系统在不同的负载情况或不同的系统环境下会有怎样的性能表现。
那么，除了进行事前和事后的基准测试去了解对环境所做的改变会产生多大的不同，还有什么方法更能证明你新安装的RAID设备将大幅改善系统的性能呢？
是的，一切都是围绕成本进行考虑，基准测试工具可以帮助你管理好数据库系统的成本。
性能测试知多少---性能需求分析
需求分析是个繁杂过程，它并非我们想象的那么简单，而性能测试需求除了要对系统的业务非常了解，还需要有深厚性能测试知识。
才能够挖掘分析出真正的性能需求。
如何获得有效的需求
1、客户方提出
客户方能提出明确的性能需求，说明对方很重视性能测试，这样的企业一般是金融、电信、银行、医疗器械等；他们一般对系统的性能要求非常高，对性能也非常了解。
提出需求也比较明确。
曾经有一个银行项目，已经到最后的性能测试极端，因为数据库设计不合理，导致性能出现很大的问题，最终不得不把整合项目作废，对于这样的项目，其实从分析设计阶段就应该考虑系统的性能问题。
性能测试也一样，对于某些项目来说越早进行越好。
当然，前期的性能测试为单元性能测试、接口性能测试，有别系统性能测试。
有时候也会碰到不懂装懂的客户，提出一些无理的需求，比如只能2000人使用的OA系统，客户要求并发用户2000，这显然是不合理的需求。
这个就要看你怎么给客户沟通了。
但是，千万别伪造数据欺骗客户。
2、根据历史数据分析
对于一些面向用户的独特产品，比较难定位市场的大小，可以先上一运营一段时间，通过运营可以搜集客户资料，比如，每月、每星期、每天的峰值业务量是多少。
用户以什么样的速度在递增中。
用户对系统的哪些功能模块使用的最多，他们所点的比例等等。
收集到这些数据之后，我们就可评估系统的系统需求指标，从而进行性能测试。
3、需求分析与定位
这里根据前期的需求分析与定位，来分析确定系统性能指标。
例如某省幼儿园管理系统。
统计全省有多少家幼儿园，系统的使用时间为幼儿到校之后，管理人员对幼儿的到校情况进行录入，以及幼儿的午饭，放学情况的录入时间。
经过与需求人员交流分析也能得到比较明确的性能指标。
4、参考历史项目或其它同行业的项目
如果公司之前有类似的项目经验，根据项目大小及上次性能测试的一些指标。
从根据项目的规模可以制定出相应的性能指标。
即使本公司没有类似的项目，但其它公司有类似的项目，例如做IPTV或者DVB计费系统的测试，可以参考电信计费系统的需求——虽然不能完全照搬数据，但是可以通过其他行业成熟的需求来了解需要测试的项目有哪些，应该考虑到的情况有哪些种。
5、参考其它资料数据
如果你做的是非常独特的产品，市场上没有此类型的产品，而且需求及市场也难以估计，那么只能从与产品相关的资料中寻找痕迹了。
不过，相信这样不确定性的产品，老板要承担的风险也是挺大的。
^_^
需要说明的是，我上面介绍的方面并非是独立的，可以综合的使用，你可以根据客户提出的指标，再根据历史数据以及参考同类型项目来进行。
这样可以更确定你的性能指标是客户（或自己）真正需要的、最符合项目需求的。
性能测试点的选取
*发生频率非常高的（例如：
某邮箱核心业务系统中的登录、收发邮件等业务，它们在每天的业务总量中占到90%以上）
*关键程度非常高的（产品经理认为绝对不能出现问题的，如登录等）
*资源占用非常严重的（导致磁盘I/O非常大的，例如某个业务进行结果提交时需要向数十个表存取数据，或者一个查询提交请求时会检索出大量的数据记录）
对性能需求点的描述
准确
如**系统必须在不超过10秒的响应时间内，处理20起登录任务。
再如发邮件时间最大不超过5秒以及平均时间在2秒以内。
一致
用户和性能测试工程师对有关术语的理解要一致，如：
并发用户数、在线用户数、注册用户数：
特定
性能测试的需求一定是有条件的。
检查系统后台关键业务数据10G、操作数据量为20K，1500个用户、500个并发用户运行的负载下，连续运行12小时过程中，业务操作是否满足性能需求。
常见性能需求
1、WEB首页打开速度5s以下，web登陆速度15s以下。
2、邮件服务支持50万个在线用户
3、计费话单成功率达到99.999%以上。
4、在100个并发用户的高峰期，邮箱的基本功能，处理能力至少达到10TPS
5、系统能在高于实际系统运行压力1倍的情况下，稳定的运行12小时
6、这个系统能否支撑200万的vu（每天登录系统的人次）vu----Virtualuser（虚拟用户）
如何把需求转换成性能指标
我们把200万vu转换成一系列的指标
™响应时间：
根据国外的一些资料，一般操作的响应时间为2，5，10秒，2秒内优秀，5秒内良好，10秒内可接受，其它一些特殊的操作，如上传，下载可以依据用户体验的情况，延长响应时间。
™吞吐量：
可以根据已经上线的类似产品进行估计。
或者，采用80/20原则进行估计。
我们经常使用的是80/20原则。
80/20原则：
又称帕累托效应，比如，80%的社会财富掌握在20%的人手里。
应用于测试：
从vu计算吞吐量？
根据80/20原则，80%的用户会在20%的繁忙时间内登陆。
则繁忙时间每秒大概会有（2000000*80%）/（24*3600*20%）=100个用户登陆，也就是说，登陆操作的吞吐量是100TPS
如何根据性能需求进行测试
其实我们上面得到的需求指标仍然是不明确的：
是验证当前硬件和软件配置能否支撑200万vu？
是测试当前的硬件和软件配置最多能支撑多少vu？
是帮助开发寻找性能瓶颈？
根据需求进行性能测试的过程：
首先，请你们当前软件和硬件配置下验证能否支撑200万vu。
如果可以支撑200万，再增加到300万看是否可以支撑。
如果不能达到200万，那么就需要寻找一下是否有性能瓶颈，将主要的性能瓶颈解决后，再看一下是否可以支撑200万，如果可以支撑，输出测试结果。
仍然不能，请评估需要添加多少硬件设备。
通过上面流程的分析，那么我们对于需求实施过程就非常明确了。
下面看来分析某邮箱系统的需求：
按照某某邮箱20000万注册用户，其中日活跃用户数为1.5%的规模计算：
日活跃用户=20000*1.5%=300万
日活跃用户人均每天发6封邮件，用户使用客户端收发邮件比例20%，则：
每天发邮件投递量=300万*6*20%=360万封
如何得到每秒的邮件数？
方式一：
严格的根据2/8原则，80%的邮件集中在20%的时间发送。
集中发邮件数：
3600000*80%=封
集中发送的时间：
24*20%=4.8小时=17280秒
每秒发送邮件数：
2880000/17280=166.7封/秒
方式二，根据某某邮箱业务模型表，每天忙时集中邮件系数0.15，邮件平均峰值系数2，则：
峰值邮件量=3600000*0.15*2/3600=300封/秒
注：
忙时集中系数=忙时业务量/全天业务量
在两种方式的分析中，方法二得出的结果是方法一的将近一倍，我们不要根据经验理所当然的去分析，要深入的了解系统，我们要对行业指标及计算方式。
如果按照第一种方式，性能测试达标了，但系统真正上线后可能远远超出了我们的评估。
2008年北京奥运运门票系统就是一个典型的案例。
再来分析系统的登录：
去年全年处理“WEB登录”交易约100万笔，考虑到3年后交易量递增到每年200万笔。
假设每年交易量集中在8个月，每个月20个工作日，每个工作日8小时，试采用80～20原理估算系统服务器高峰期“WEB登录”的交易吞吐量应达到怎样的一个处理能力
200万/8=25万/月
25万/20=1.25万/日
1.25万*80%/（8*20%*3600）=1.74TPS
----------------------
上面的小案例算是抛出的一块砖，需求开发难度要远远大于需求管理，在实际工作中常常需要我们为客户开发这部分性能需求。
所以，在追求技术的基础上，请更多的了解分析你的项目及行业指标。
性能测试知多少----性能测试分类之我见
从这一篇开始，虫师向性能方面发力。
翻看自己的博客，最早的时候热衷于jmeter，于是写了几篇图文并茂的文章（其实，主要是操作截图加文字描述），之后，由于看到好多朋友关于性能的知识什么都不知道，下载个loadrunner就说要做性能测试，结果可想而知，遇到各种概念与使用问题。
于是写了《在做性能测试之前需要知道什么》《在做性能测试之后需要知道些什么》，关于loadrunner的我没有写一篇博客，因为介绍loadrunner的网站、资料、书籍和视频太多了。
我想这个系列我也会把关注点放在思想上。
性能测试常见分类
常会别人说到性能测试、负载测试、压力测试、并发测试，很多人都是混合使用，或者一会叫压力测试，一会叫并发测试。
这些概念除了非测试人员分不清楚，甚至许多专业测试人员也对这些名词也很模糊。
关于这个分类我翻阅了几个本比较好的书籍，他们讲的也比较模糊，没有给出本质上的区别。
只是从不同角度和关注点来解释。
好吧我们先来看他们之间比较普遍的解释。
性能测试（狭义）
性能测试方法是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。
通俗地说，这种方法就是要在特定的运行条件下验证系统的能力状态。
特点：
1、这种方法的主要目的是验证系统是否有系统宣称具有的能力。
2、这种方法要事先了解被测试系统经典场景，并具有确定的性能目标。
3、这种方法要求在已经确定的环境下运行。
也就是说，这种方法是对系统性能已经有了解的前提，并对需求有明确的目标，并在已经确定的环境下进行的。
负载测试
通过在被测系统上不断加压，直到性能指标达到极限，例如“响应时间”超过预定指标或都某种资源已经达到饱和状态。
特点：
1、这种性能测试方法的主要目的是找到系统处理能力的极限。
2、这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测试系统的业务压力量和典型场景、使得测试结果具有业务上的意义。
3、这种性能测试方法一般用来了解系统的性能容量，或是配合性能调优来使用。
也就是说，这种方法是对一个系统持续不段的加压，看你在什么时候已经超出“我的要求”或系统崩溃。
压力测试（强度测试）
压力测试方法测试系统在一定饱和状态下，例如cpu、内存在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误
特点：
1、这种性能测试方法的主要目的是检查系统处于压力性能下时，应用的表现。
2、这种性能测试一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。
3、这种性能测试方法一般用于测试系统的稳定性。
也就是说，这种测试是让系统处在很大强度的压力之下，看系统是否稳定，哪里会出问题。
并发测试
并发测试方法通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题。
特点：
1、这种性能测试方法的主要目的是发现系统中可能隐藏的并发访问时的问题。
2、这种性能测试方法主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。
3、这种性能测试方法可以在开发的各个阶段使用需要相关的测试工具的配合和支持。
也就是说，这种测试关注点是多个用户同时（并发）对一个模块或操作进行加压。
配置测试
配置测试方法通过对被测系统的软\硬件环境的调整，了解各种不同对系统的性能影响的程度，从而找到系统各项资源的最优分配原则。
特点：
1、这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。
2、这种性能测试方法一般在对系统性能状况有初步了解后进行。
3、这种性能测试方法一般用于性能调优和规划能力。
也就是说，这种测试关注点是“微调”，通过对软硬件的不段调整，找出这他们的最佳状态，使系统达到一个最强的状态。
可靠性测试
在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。
特点：
1、这种性能测试方法的主要目的是验证是否支持长期稳定的运行。
2、这种性能测试方法需要在压力下持续一段时间的运行。
（2~3天）
3、测试过程中需要关注系统的运行状况。
也就是说，这种测试的关注点是“稳定”，不需要给系统太大的压力，只要系统能够长期处于一个稳定的状态。
上面的分类绝非全面，还有失效性测试，就是系统局部发生问题时，其它模块是否可以正常的运行。
这个在极少数情况下进行，这里就不介绍了。
性能测试分类之我见
上面的类分完了，似乎得到不少专家的认同，并无不妥。
但我们在性能测试过程中真的能把它们区别分的很清楚么？
你能严格区分出你这次的测试到底并发测试还是压力测试。
笔者第一点不太赞同的是对“性能测试”的定义。
笔者认为性能测式测试包含了上面的所有分类。
而这种性能测试的定义只是一种狭义上的“性能测试”，属于性能测试的一种。
性能测试是相对功能测试来说的。
他们之间最本质的区别就是对系统有处理能力是否够成压力。
如果一个用户的一个操作（比如超大数据量的查询）对系统够成了压力，我也可以视其为性能测试。
其实，可以这样来划分性能测试
上面定交了那么多分类，是不是有点晕了。
其实，以笔者认为我们进行性能测试时关注的就两点。
耐力和爆发力。
初高中时练过几年体育，最好时代表学校参加县体育比赛，不过是去垫底的。
哈哈！
哈一个体育运动员来说，那么多的体育项目，其实，考核他的就两方面。
一是爆发力。
二是耐力。
爆发力：
拿一个举重选手来说，他的重点在重量上，因为你只要能举起三秒就算你成功了。
关键是看你能举起一个什么样的重量。
耐力：
拿一个马拉松运动员来说，你百米速度跑得再快没用。
关键是这40公里路程中，最先跑到终点的人才是赢家。
整体协调性：
当然，身为一个教练员，我在选拔选手的时候，除了看这个运动员的耐力和爆发力，身体的整体协调性也是我考核的一个很重要的指标。
比如一个运行员身体各位部位练得非常强壮，但右臂先天性萎缩。
他的跑步成绩虽然不错。
但他在跑的过程中，身体有各个部分都在分担右臂的不足。
右臂影响了整个体能的发挥。
再到系统的性能上说，爆发力就是这个系统能承受的最大压力，没准这个系统承受的压力很大。
但过半个小时之间就挂掉了。
耐力就是这个每系统长时间处于压力下的稳定性，这系统超级稳定，跑个几十年都不用重启服务器。
那么整体协调性就是看系统有没系统瓶颈，需不需要进行系统调优。
在做性能测试时请忘掉分类
这里只是告诉在做性能测试时不要想这个测试是属于性能测试的哪一类呢？
是并发性测呢？
还是压力测试？
我们还拿上面的教练员选拔选手做例子。
记得我进校体队的时候，教练说让我跑两圈。
然后，我就开始围绕着操场跑起来。
你说教练让我跑两圈是想看我的什么能力？
1、双腿的考核，一个是步幅，就是步与步之间的距离。
一个是频率，两腿交替的频率。
如果你一步拉得很大的话，那么频率一定会下降。
如果想提高频率的话，那么一定会影响到步幅的大小。
2、双臂的考核，肩膀是否放松，摆臂是否有力，双臂的摆动与双腿的摆动是否协调。
3、呼吸是否匀称，目前的速度可以跑几圈。
我只做了一项体育运行，就考核了我这么多内容。
我们在做一个性能测试时也不局限在某一分类上，也可能我们的一个测试包含多个分类。
《web性能测试实战》：
这么多类型的性能测试看起来很吓人，实际上它他们大多是密切相关的。
例如，运行8个小时来测试系统是否可靠，而这个测试极有可能包含了可靠性能测、强度测试、并发测试、负载测试，等等。
因此，在实施性能测试时决不能割裂它们的内部联系去进行，而应该分析它们之间的关系，以一种高效率的方式来设计性能测试。
性能测试知多少---性能测试工具原理与架构
在性能测试的学习过程中，坚持思想与工具（分开）并行，当前面世面上的性能测试书籍大多把理论与loadrunner融为一体讲解，这样做是正确的，因为有一些性能名词概念也源于工具。
但是，性能测试不是loadrunner，所有的作者也是这么认为的。
但他们在讲性能测试的时候讲的就是loadrunner有，只是讲的多少不同罢啦。
你是否觉得我对loadrunner有仇？
我之所以将其分开来学，只是希望自己在学习性能测试的时候不要被loadrunner局限了而已。
只是觉得在做性能测试时不要带loadrunner的思维，这样更容易把握性能测试的本质。
性能测试工具，从广义上讲，在性能测试过程中使用到的所有工具都可以称其为性能测试工具。
从狭义上来讲，我们可以把性能测试工具分为服务器端性能测试工具与前段性能测试工具。
服务器端性能测试工具也我们测试人员通常所认为的性能测试工具。
LoadRunner、JMeter、SilkPerformance、服务器端压力性能工具需要支持产生压力和负载，录制和生成脚本，设置和部署场景，产生并发用户和向系统施加持续的压力。
前端性能测试工具应用比较广泛，开发人员，前端开发人员、测试人员都会经常用到。
Firebug、fildder2、Yslow、前端性能测试工具只需要关于心浏览器等客户端工具对具体需要展现的页面的处理过程。
服务器性能测试工具原理
性能测试工具的主要作用是通过模拟生产环境中的真实业务操作，对被测试系统实行压力负载测试，监视被测试系统在不同业务、不同压力性能下的性能表现，找出潜在的性能瓶颈进行分析、优化。
客户
升级会员 