淘宝性能测试白皮书本.pdf

淘宝性能测试白皮书本.pdf

《淘宝性能测试白皮书本.pdf》由会员分享，可在线阅读，更多相关《淘宝性能测试白皮书本.pdf（32页珍藏版）》请在冰点文库上搜索。

TAOBAOPERF-TEST淘宝性能测试团队淘宝性能测试白皮书淘宝性能测试白皮书淘宝性能测试白皮书淘宝性能测试团队版本号：

V1.0发布时间：

2010年3月31日1A-PDFWatermarkDEMO:

Purchasefromwww.A-PDF.comtoremovethewatermarkTAOBAOPERF-TEST淘宝性能测试团队淘宝性能测试白皮书序言序言二零零九，岁在己丑，秋末冬初，会于产品研发之测试，修性能书也，群贤毕至，少长咸集。

此地有系统框架，API接口；又有Web应用，无线性能，分布式各大中心，列坐其次。

虽无丝竹管弦之盛，一书一典，亦足以畅叙幽情。

是日也，天朗气清，惠风和畅。

仰观系统之大，俯察测试之盛。

所以游目骋怀，足以极性能之娱，信可乐也。

测试之相与，俯仰淘宝，或接口功能，测试一室之内；或安全性能，放浪形骸之外。

虽用例万殊，方法不同，当其欣于所遇，暂得于己，怏然自足，曾不知新人倍增；及其所之未知，能力各异，感慨系之矣。

向之所能，俯仰之间，已为陈迹，犹不能不以之兴怀。

况系统复杂，调优艰难。

马云曰：

“系统之不稳。

岂不痛哉！

”每览昔人性能测试成就之由，若合一契，未尝不临技能嗟叹，不能喻之于怀。

固知技术名利为虚诞，齐知识业绩为妄作。

后之视今，亦犹今之视昔。

憾夫！

故列叙性能理论实践，录其指标模型策略，虽世殊事异，性能技术，其致一也。

后之览者，亦将有感于斯性能白皮书。

郭芙淘宝网测试掌门人2009年11月18日于杭州2TAOBAOPERF-TEST淘宝性能测试团队淘宝性能测试白皮书目录目录序言.2目录.3引言.5性能测试指标.5Vuser虚拟用户.5Transaction事务.5TPS每秒事务数.6PVPageView.6PeakPV高峰PageView.6Concurrency并发.7Scenario场景.7ResponseTime响应时间.7ThinkTime思考时间.7CPU资源.8Load负载.9Std.Deviation标准差.10性能测试模型.10PV计算模型.10PV-TPS转换模型.12TPS波动模型.12共享中心性能测试模型.13前端页面性能测试模型.14性能测试策略.15性能测试评估.16关键业务.17日PV量.17逻辑复杂度.17运营推广计划.173TAOBAOPERF-TEST淘宝性能测试团队淘宝性能测试白皮书其它.17性能测试类型.18性能测试压力变化模型.18性能测试类型.181.性能测试.182.负载测试.193.压力测试.194.稳定性测试.19性能测试执行方法.19单场景.19混合场景.20性能监控.20监控指标.20监控工具.21监控步骤.23性能分析.24分析原则.24分析信息来源.24分析标准.24分析工具.24性能测试通过标准.27性能测试流程.28性能测试流程图.28性能测试流程主要活动.29性能测试文件模版.30结束语.30参考文献.31版本更新说明.32作者介绍.324TAOBAOPERF-TEST淘宝性能测试团队淘宝性能测试白皮书引言引言淘宝网自创立以来，除了对功能的要求很高以外，对性能的要求也越来越高。

从最初的系统框架性能测试、TOP-API接口性能测试，到现在的Web应用性能测试，无线性能测试领域，淘宝性能测试在不断向前发展，横向、纵向都在不断深入、拓宽，不断创新。

经过五彩石项目对淘宝的整体应用重构之后，淘宝网形成了以四个中心为应用基础的分布式架构体系。

而分布式网站的性能，很大程度上决定了网站的竞争优势。

但是，一个应用的性能由多方面因素决定，这样就增加了性能测试和性能调优的难度，也扩大了性能测试的广度，这是一个挑战。

专业的测试需要专业的团队，我们的团队也应运而生。

本性能测试白皮书旨在以理论指导实践，以实践修正理论，将会从以下几个方面介绍和分析淘宝的性能测试：

性能测试指标、淘宝性能测试模型、性能测试策略、性能测试评估、性能测试类型、性能测试执行方法、性能监控和性能分析、性能测试通过标准，以及性能测试流程和文件模版。

同时，也是让更多的人更好地了解淘宝性能测试和性能调优，参与性能测试，共同将淘宝网做得更大、更强、更稳定，并且期望淘宝的性能测试能成为电子商务性能测试业界的标准。

性能测试指标性能测试指标Vuser虚拟用户虚拟用户Virtualuser，模拟真实业务逻辑步骤的虚拟用户，虚拟用户模拟的操作步骤都被记录在虚拟用户脚本里。

Vuser脚本用于描述Vuser在场景中执行的操作。

虚拟用户在性能场景中有以下12个状态，Down,Pending,Init,Ready,Running,Rendezous,Passed,Failed,Error,GradualExiting,Exiting,Stopped.如图1所示。

图1Transaction事务事务事务是性能测试脚本的一个重要特性。

要度量服务器的性能，需要定义事务，每个事务都包含事务开始和事务结束标记。

事务用来衡量脚本中一行代码或多行代码的执行所耗费的时间。

可以将事务开始放置在脚本中某行或者多行代码的前面，将事务结束放置在该行或者多行代码的后面，在该脚本的虚拟用户运行时，这个事务将衡量该行或者多行代码的执行花费了多长时间。

在性能测试脚本中，事务的标记会以下列形式出现（举例语言为类JAVA语言模式）。

如图2所示。

5TAOBAOPERF-TEST淘宝性能测试团队淘宝性能测试白皮书trylr.start_transaction（QueryItemById）;finalItemResultDOitemResult=itemQueryService.queryItemById（itemIdDo,options,mainDbRoute）;finalItemDOitem=itemResult.getItem（）;catch（finalExceptione）/TODOAuto-generatedcatchblocke.printStackTrace（）;finallylr.end_transaction（QueryItemById,lr.AUTO）;图2TPS每秒事务数每秒事务数TPS（TransactionPerSecond）每秒钟系统能够处理的交易或事务的数量，它是衡量系统处理能力的重要指标。

TPS是LoadRunner中重要的性能参数指标。

图3是TPS单位时间段内的分布图。

图3PVPageViewPV是PageView的缩写。

用户通过浏览器访问页面，对应用服务器产生的每一次请求，记为一个PV。

淘宝性能测试环境下，将这个概念做了延伸，系统真实处理的一个请求，视为一个PV。

即，PV的概念也适用于接口。

PeakPV高峰高峰PageView即PV峰值，指一天中PV数达到的最高峰。

6TAOBAOPERF-TEST淘宝性能测试团队淘宝性能测试白皮书Concurrency并发并发并发分为狭义和广义两类。

狭义的并发，即所有的用户在同一时刻做同一件事情或操作，这种操作一般针对同一类型的业务，或者所有用户进行完全一样的操作，目的是测试数据库和程序对并发操作的处理。

广义的并发，即多个用户对系统发出了请求或者进行了操作，但是这些请求或操作可以是不同的。

对整个系统而言，仍然有很多用户同时进行操作。

狭义并发强调对系统的请求操作是完全相同的，多适用于性能测试、负载测试、压力测试、稳定性测试场景；广义并发不限制对系统的请求操作，多适用于混合场景、稳定性测试场景。

Scenario场景场景性能测试过程中为了模拟真实用户的业务处理过程，在LoadRunner中构建的基于事务、脚本、虚拟用户、运行设置、运行计划、监控、分析等的一系列动作的集合，称之为性能测试场景。

场景中包含了待执行脚本、脚本组、并发用户数、负载生成器、测试目标、测试执行时的配置条件等。

ResponseTime响应时间响应时间响应时间是指从客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束所经历的时间，响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成。

在性能测试结果分析中，性能场景中事务的响应时间请参阅图4所示，事务响应时间分为事务最小响应时间、事务平均响应时间、事务最大响应时间。

图4ThinkTime思考时间思考时间模拟正式用户在实际操作时的停顿间隔时间。

从业务的角度来讲，思考时间指的是用户在进行操作时，每个请求之间的间隔时间。

在测试脚本中，思考时间体现为脚本中两个请求语句之间的间隔时间。

7TAOBAOPERF-TEST淘宝性能测试团队淘宝性能测试白皮书在脚本中的表现形式如下图5所示，加入的思考时间为10秒。

lr_think_time（10）;lr_start_transaction（LimitPromotion）;web_submit_data（buy_now.jhtml,Action=http:

/$hostname$:

$port$,Method=POST,TargetFrame=,RecContentType=text/html,Referer=http:

/:

/$hostname$:

$port$/auction/item_detail-0db2-auc_ID.jhtml,Snapshot=t18.inf,Mode=HTML,ITEMDATA,Name=catPath,Value=,ENDITEM,Name=item_id,Value=auc_ID,ENDITEM,Name=auction_id,Value=auc_IDgeng,ENDITEM,Name=auction_type,Value=b,ENDITEM,Name=title,Value=2009-08-1710:

24162,ENDITEM,Name=x_id,Value=db2,ENDITEM,Name=seller_id,Value=b929dfa7858c0e5a054fffd3550e68a2,ENDITEM,Name=allow_quantity,Value=100000,ENDITEM,Name=seller_nickname,Value=tbtest33,ENDITEM,LAST）;lr_end_transaction（LimitPromotion,LR_AUTO）;图5CPU资源资源CPU资源是指性能测试场景运行的这个时间段内，应用服务系统的CPU资源占用率。

CPU资源是判断系统处理能力以及应用运行是否稳定的重要参数。

应用服务系统可以包括应用服务器、Web服务器、数据库服务器等。

性能测试过程中，对CPU的监控以及分析报告、图表有LoadRunner自带监控分析、有Linux系统输出以及手工汇总、有第三方工具监控分析等。

在此以LR监控分析图表（图6）、JVM自带CPU监控图表（图7）为例。

8TAOBAOPERF-TEST淘宝性能测试团队淘宝性能测试白皮书图6图7Load负载负载系统平均负载，被定义为在特定时间间隔内运行队列中的平均进程数。

如果一个进程满足以下条件则其就会位于运行队列中：

1.它没有在等待I/O操作的结果。

2.它没有主动进入等待状态（也就是没有调用“wait”）。

3.没有被停止（例如：

等待终止）。

性能测试结果分析Load分布如图8所示。

9TAOBAOPERF-TEST淘宝性能测试团队淘宝性能测试白皮书图8Std.Deviation标准差标准差该标准差根据数理统计的概念得来，标准差越小，说明波动越小，系统越稳定，反之，标准差越大，说明波动越大，系统越不稳定。

包括响应时间标准差、TPS标准差、RunningVuser标准差、Load标准差、CPU资源利用率标准差、WebResources标准差等。

举例响应时间标准差，如图9所示，事务SellerSaveItem的响应时间为0.043秒，响应时间标准差为0.01，如图红色圈住所示。

图9性能测试模型性能测试模型PV计算模型计算模型为了让性能测试的PV计算更接近生产线真实情况，利用现有最新的数据得出性能测试PV的计算公式。

首先，通过http:

/采集现有数据，图10所示的是任意选择一天得到的分布图，6:

00AM到次日的6:

00AM，共24小时。

10TAOBAOPERF-TEST淘宝性能测试团队淘宝性能测试白皮书图10经过长期监控，发现任何一天的分布图都与上图类似，故将这种分布视为整个淘宝网的浏览量分布。

其次，进行数据统计：

为了和目前真实情况更接近，选择最近一段时间的数据分布来做样本，记录下系统能够监控到的最短时间间隔的数据，考察其值的走势，并且找出每一天的最大值，抽样出每个时刻的值与当天最大值的比例，以此比例值的趋势，得出数据分布趋势，如图11所示。

监控系统最精确可以采集到每3分钟的数据，一天24小时可以采集到480个点。

00.20.40.60.81图11采用微积分思想，将每个时间点视为一个矩形，可以通过求和的方式求出整个分布图的面积，如图12所示。

00.10.20.30.40.50.60.70.80.9111TAOBAOPERF-TEST淘宝性能测试团队淘宝性能测试白皮书图12根据80/20原理，找出占据总体面积80%所用的时间，再计算出平均PV量。

选择尽可能大的点计算出占据总体80%的面积，发现点的个数是240，那么意味着此时间长度为总时间长度的50%，则80/20原则在此可以转换成80/50原则，则有每台服务器每秒平均PV量=（80%*总PV）/（24*60*60*（240/480）/服务器数量整理后得每台服务器每秒平均PV量=（1.6*总PV）/（24*60*60）/服务器数量进而计算出占总面积80%的PV平均值与整个图中的最高峰值的比，可以得出最高峰的PV量是1.2倍的平均PV量。

即每台服务器每秒高峰PV量=（1.2*1.6*总PV）/（24*60*60）/服务器数量整理后得每台服务器每秒高峰PV量=（1.92*总PV）/（24*60*60）/服务器数量PV-TPS转换模型转换模型为了使PV在性能测试环境下可量化，根据PV的概念，通过以下方式将其转换成TPS。

1.性能测试脚本中，只保留与性能点相关的内容，异步处理的，保留多个请求，从而确保压力目标。

2.在执行场景中，不模拟浏览器缓存，确保每次请求都到达应用服务器，使得LoadRunner的一个请求等同于一个PV。

3.在执行场景中，每次迭代，都模拟一个新用户，而且清除用户缓存信息，确保每个用户每次发送请求都是全新的。

结论：

通过以上三步，将PV转化成性能测试工具可识别的TPS。

换言之，1PV=1TPS。

TPS波动模型波动模型TPS是性能测试过程中的重要参考指标，在淘宝的性能测试设计、执行、分析、评估等各个阶段，TPS都被看作是非常重要的一个环节；同时，在性能测试是否通过的衡量参数指标里，它也有着举足轻重的影响。

众所周知，性能测试会依赖于特定的硬件、软件、应用服务、网络资源等，所以在性能场景执行期间，TPS可能会表现为稳定，或者波动，抑或遵循一定的上升或下降趋势。

TPS表现轨迹可以总结为两大类：

一类是TPS有明显的大幅波动，不稳定。

例如TPS轨迹缓慢下降，缓慢上升后骤降，呈瀑布型，呈矩形，分时间段有规律的波动，无规律的波动等。

这些TPS的波动轨迹反映出被测试的性能点存在性能瓶颈，需要性能测试工程师与开发工程师查找性能瓶颈的原因。

另一类是TPS轨迹比较平稳，但是也存在波动现象。

该类波动不明显，很难直接确定是否存在性能瓶颈。

如果单场景性能测试、稳定性测试结果显示TPS达到了期望值，是否就确定TPS满足了期望呢？

由于程序执行过程中服务器会有活动，造成TPS不可能是一条完整的直线，那么多大的TPS波动范围认为是可以被接受的呢？

LoadRunnerTPS分析图中涉及到了4个重要的参数，最大值、平均值、最小值和标准差值；平均值和标准差是衡量TPS是否稳定的重要因子。

在此，我们强调一下TPS平均值和TPS标准差的概念。

TPS平均值是在场景执行过程中，被测系统在指定时间段内的平均每秒处理的事务数量。

TPS标准差是根据数理统计的概念得来，反映被测系统的波动情况，标准差越小，说明波动越小，系统越稳定，反之，标准差越大，说明波动越大，系统越不稳定。

既然HPMercury提供了这么好的数据给用户，那我们就要充分运用它。

目前淘宝性能测试，JAVAWeb和JAVA接口占了绝大部分，JAVAWeb和JAVA接口12TAOBAOPERF-TEST淘宝性能测试团队淘宝性能测试白皮书在系统处理能力上有非常大的区别，如果将JAVAWeb和JAVA接口分别做内部类比，由于是不同的应用，每个性能点的TPS平均值、TPS标准差也是差距非常大。

因此，如果定义一个TPS或者TPS标准差作为一个基线的话，不能应用到当前淘宝各类应用服务系统的性能测试中。

这也就说明了如果纯粹拿一个TPS平均值或者TPS标准差，不能完全说明TPS是否稳定。

而我们知道，标准差与平均数的比值称为离散系数或变异系数，变异系数可以消除单位和（或）平均数不同对两个或多个资料变异程度比较的影响。

标准变异系数是一组数据的变异指标与其平均指标之比，它是一个相对变异指标。

因此，淘宝性能测试团队根据离散系数提出一个TPS波动范围的概念，定义为TPS标准差除以TPS平均值，如公式1所示。

t（TPS波动范围）=TPS标准差TPS平均值100%公式1由此来观察TPS标准差与TPS的比值t，如果这个比值t超过了一定的范围，就确认这个性能点的TPS不够稳定，也间接证明被测系统响应波动大而不满足性能期望。

性能测试团队搜集了以往20个典型项目中的75个性能场景，针对JAVAWeb与JAVA接口的性能测试和稳定性测试，做了统计分析，得出可接受的TPS波动范围。

如表1所示。

被测系统种类被测系统种类测试是否通过测试是否通过测试类型测试类型超时概率超时概率采样时间采样时间（s）可接受的最大波可接受的最大波动范围动范围JAVA接口是性能测试低于万分之一15%8%JAVA接口是稳定性测试低于万分之一605%8%JAVAWeb是性能测试低于万分之一14%6%JAVAWeb是稳定性测试低于万分之一604%6%表1建立TPS波动模型的出发点是为淘宝性能测试以及项目组建立一个可参考的标准，更为有效的控制、降低项目上线后的风险。

有了这个统计模型，在性能测试衡量TPS是否稳定的时候，就有了一个参考依据，如果TPS的波动范围高于表1所示，性能测试工程师就要配合项目组开发人员查找定位性能瓶颈，并做进一步的性能优化。

注意：

这个TPS波动模型是会随着淘宝各应用性能表现而相应变更的。

当然，模型是基于搜集来的数据、分析、论证得出，也不排除一些特殊的例子，在具体的性能测试应用中，需要做出更为专业的评估。

共享中心性能测试模型共享中心性能测试模型淘宝共享中心应用，管理着淘宝网核心数据和业务流程，直接与数据库或缓存服务器交互，统一对全网上层APP提供服务。

因此，它们扮演着极其重要的角色，其性能和稳定性的要求都非常高。

为了更好的模拟共享中心的业务情况，在实践中探索出一个适用于当前现状的性能测试模型。

如图13所示。

13TAOBAOPERF-TEST淘宝性能测试团队淘宝性能测试白皮书图13该共享中心性能测试模型由三部分组成：

1.性能测试工具（LoadRunner）。

2.Client测试代码集。

3.目标Server。

该模型中，性能测试工具（LoadRunner）可通过WindowsSockets协议，调用Client测试代码集中的测试场景，再由被调用测试场景对目标Server发起请求。

三方共同完成整个性能测试场景。

该模型有以下三个优点：

1.通过水平扩展Client，可以模拟任意多个HSF连接，最大限度模拟生产环境的真实场景，解决以往模型只能模拟一个HSF连接的弊端。

2.Server端作为承受压力端，也可以水平扩展，模拟多Server负载均衡、容灾等场景，解决现有单台机器测试，扩展难度大的弊端。

3.LoadRunner作为集中控制端，可以统一发送请求、统一收集数据，结果准确、可靠，并可以通过代理进行扩展。

结论：

从上述三点，可以看出，该模型不仅能真实的模拟淘宝网现有的调用架构，也能灵活扩展，模拟出超大规模并发请求的场景。

适用于目前共享中心的性能测试工作。

前端页面性能测试模型前端页面性能测试模型随着大淘宝战略的开展，淘宝网的用户群体日益增大。

与此同时，网站前端页面的性能得到越来越多的关注，前端性能，已经成为不可或缺的部分。

为了更好、更快速的测试前端页面性能，为前端优化工作提供依据，定制了前端性能测试模型。

如图14所示。

14TAOBAOPERF-TEST淘宝性能测试团队淘宝性能测试白皮书图14该前端页面性能测试模型由三部分组成：

1.Selenium，定期自动运行批量任务。

2.YSlow，FireFox浏览器插件FireBug的插件，前端性能测试工具。

3.ShowSlow，处理数据，展现结果。

该模型中，使用者在Selenium中定制任务，Selenium按照设定，定期自动运行批量任务，由各个任务分别调用YSlow，YSlow对前端页面进行评分，并将评分结果发送给ShowSlow入库。

最终由ShowSlow展现测试结果。

该模型有以下三个优点：

1.实现测试、存储、展现自动化，提高前端性能测试效率。

2.框架化，简化前端性能测试步骤，易学易用。

3.指导性强，YSlow能给出性能优化建议。

结论：

从上述优点，可以看出，前端性能测试模型很实用，特别是根据测试通过标准易于判断，而且能给出优化建议。

性能测试策略性能测试策略性能测试经过反复摸索，已经确立了成型的操作性非常强的整套性能测试策略，从性能测试环境，到性能测试数据、执行、调优、性能评估等等。

具体策略如下：

1.模拟生产线真实的硬件环境。

架设与生产环境相似的性能测试环境，使用物理机作为服务器。

例如，使用4核CPU、4G内存的机器模拟生产环境APP应用服务器；使用共用存储的数据库服务器；使用负载均衡模拟共享中心的应用。

2.服务器置于同一机房，最大限度避免网络问题。

所有性能测试的服务器都放置在同一个机房，属于同一个网段，服务器与服务器之间的网络交互通过交换机进行。

3.以PV为切入点，通过模型将其转换成性能测试可量化的TPS。

互联网的特点，是在线用户不断变化，很难统计到具体某个应用的在线用户数；但是页面是固定的，可以统计的。

用户U访问了P页面的行为，是能捕获的。

换句话，对于页面P，不管当前有100个用户，还是1000个用户在使用，页面的PageView都是可以统计到的。

因此，以PV为性能测试切入点，作为淘宝性能测试的突破口。

通过这种方式，可以将页面流量直接转化成PageView，作为性能测试的预期目标，而削弱在线用户数和并发用户数。

得到PV数值之后，再通过PV计算模型、PV-TPS转换模型，将它转化成测试工具可以衡量的指标TPS，从而使复杂的模型变得简单化、可衡量化。

4.性能测试数据分为基础数据和业务数据两部分。

性能测试数据库和功能测试库相互独立。

性能测试数据分为基础数据和业务数据两部分。

基础数据，指为了使表中的数据达到一定的数量级而填充的数据，目的是测试出15TAOBAOPERF