淘宝性能测试白皮书_V1.0

序言 二零零九，岁在己丑，秋末冬初，会于产品研发之测试，修性能书也，群贤 毕至，少长咸集。此地有系统框架，API 接口；又有 Web 应用，无线性能，分 布式各大中心，列坐其次。虽无丝竹管弦之盛，一书一典，亦足以畅叙幽情。 是日也，天朗气清，惠风和畅。仰观系统之大，俯察测试之盛。所以游目骋 怀，足以极性能之娱，信可乐也。 测试之相与，俯仰淘宝，或接口功能，测试一室之内；或安全性能，放浪形 骸之外。虽用例万殊， 方法 快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载 不同，当其欣于所遇，暂得于己，怏然自足，曾不知 新人倍增；及其所之未知，能力各异，感慨系之矣。向之所能，俯仰之间，已为 陈迹，犹不能不以之兴怀。况系统复杂，调优艰难。马云曰：“系统之不稳。岂 不痛哉！” 每览昔人性能测试成就之由，若合一契，未尝不临技能嗟叹，不能喻之于怀。 固知技术名利为虚诞，齐知识业绩为妄作。后之视今，亦犹今之视昔。憾夫！故 列叙性能理论实践，录其指标模型策略，虽世殊事异，性能技术，其致一也。后 之览者，亦将有感于斯性能白皮书。 郭芙 淘宝网测试掌门人 2009 年 11 月 18 日于杭州 淘宝性能测试团队 淘 宝 性能测试白皮书 2 目录 序言........................................................................................................................................... 2 目录........................................................................................................................................... 3 引言........................................................................................................................................... 5 性能测试指标 ........................................................................................................................... 5 Vuser虚拟用户 5 Transaction事务 5 TPS每秒事务数 6 PV Page View 6 Peak PV 高峰Page View 6 Concurrency并发 7 Scenario场景 7 Response Time响应时间 7 Think Time思考时间 7 CPU资源 8 Load负载 9 Std. Deviation标准差 10 性能测试模型 ......................................................................................................................... 10 PV计算模型 10 PV->TPS转换模型 12 TPS波动模型 12 共享中心性能测试模型 ..................................................................................................... 13 前端页面性能测试模型 ..................................................................................................... 14 性能测试策略 ......................................................................................................................... 15 性能测试评估 ......................................................................................................................... 16 关键业务 ............................................................................................................................. 17 日PV量 17 逻辑复杂度 ......................................................................................................................... 17 运营推广计划 ..................................................................................................................... 17 淘宝性能测试团队 淘 宝 性能测试白皮书 9 其它 ..................................................................................................................................... 17 性能测试类型 ......................................................................................................................... 18 性能测试压力变化模型 ..................................................................................................... 18 性能测试类型 ..................................................................................................................... 18 1. 性能测试.................................................................................................................. 18 2. 负载测试.................................................................................................................. 19 3. 压力测试.................................................................................................................. 19 4. 稳定性测试.............................................................................................................. 19 性能测试执行方法 ................................................................................................................. 19 单场景 ................................................................................................................................. 19 混合场景 ............................................................................................................................. 20 性能监控 ................................................................................................................................. 20 监控指标 ............................................................................................................................. 20 监控工具 ............................................................................................................................. 21 监控步骤 ............................................................................................................................. 23 性能 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 ................................................................................................................................. 24 分析原则 ............................................................................................................................. 24 分析信息来源 ..................................................................................................................... 24 分析标准 ............................................................................................................................. 24 分析工具 ............................................................................................................................. 24 性能测试通过标准 ................................................................................................................. 27 性能测试流程 ......................................................................................................................... 28 性能测试流程图 ................................................................................................................. 28 性能测试流程主要活动 ..................................................................................................... 29 性能测试文件模版 ................................................................................................................. 30 结束语 ..................................................................................................................................... 30 参考文献 ................................................................................................................................. 31 版本更新说明 ......................................................................................................................... 32 作者介绍 ................................................................................................................................. 32 引言 淘宝网自创立以来，除了对功能的要求很高以外，对性能的要求也越来越高。从最初的 系统框架性能测试、TOP-API 接口性能测试，到现在的 Web 应用性能测试，无线性能测试 领域，淘宝性能测试在不断向前发展，横向、纵向都在不断深入、拓宽，不断创新。 经过五彩石项目对淘宝的整体应用重构之后，淘宝网形成了以四个中心为应用基础的分 布式架构体系。而分布式网站的性能，很大程度上决定了网站的竞争优势。但是，一个应用 的性能由多方面因素决定，这样就增加了性能测试和性能调优的难度，也扩大了性能测试的 广度，这是一个挑战。专业的测试需要专业的团队，我们的团队也应运而生。 本性能测试白皮书旨在以理论指导实践，以实践修正理论，将会从以下几个方面介绍和 分析淘宝的性能测试：性能测试指标、淘宝性能测试模型、性能测试策略、性能测试评估、 性能测试类型、性能测试执行方法、性能监控和性能分析、性能测试通过标准，以及性能测 试流程和文件模版。同时，也是让更多的人更好地了解淘宝性能测试和性能调优，参与性能 测试，共同将淘宝网做得更大、更强、更稳定，并且期望淘宝的性能测试能成为电子商务性 能测试业界的标准。 性能测试指标 Vuser虚拟用户 Virtual user，模拟真实业务逻辑步骤的虚拟用户，虚拟用户模拟的操作步骤都被记录在 虚拟用户脚本里。Vuser 脚本用于描述 Vuser 在场景中执行的操作。 虚拟用 户在 性能场 景中 有以下 12 个状态 ， Down, Pending, Init, Ready, Running, Rendezous, Passed, Failed, Error, Gradual Exiting, Exiting, Stopped. 如图 1 所示。 图 1 Transaction事务 事务是性能测试脚本的一个重要特性。要度量服务器的性能，需要定义事务，每个事务 都包含事务开始和事务结束标记。事务用来衡量脚本中一行代码或多行代码的执行所耗费的 时间。可以将事务开始放置在脚本中某行或者多行代码的前面，将事务结束放置在该行或者 多行代码的后面，在该脚本的虚拟用户运行时，这个事务将衡量该行或者多行代码的执行花 费了多长时间。 在性能测试脚本中，事务的标记会以下列形式出现（举例语言为类 JAVA 语言模式）。 如图 2 所示。 try { lr.start_transaction("QueryItemById"); final ItemResultDO itemResult = itemQueryService.queryItemById(itemIdDo, options, mainDbRoute); final ItemDO item = itemResult.getItem(); } catch (final Exception e) { // TODO Auto-generated catch block e.printStackTrace(); } finally { } lr.end_transaction("QueryItemById", lr.AUTO); 图 2 TPS每秒事务数 TPS(Transaction Per Second)每秒钟系统能够处理的交易或事务的数量，它是衡量系统处 理能力的重要指标。TPS 是 LoadRunner 中重要的性能参数指标。 图 3 是 TPS 单位时间段内的分布图。 TAOBAO PERF-TEST图 3 PV Page View PV 是 Page View 的缩写。用户通过浏览器访问页面，对应用服务器产生的每一次请求， 记为一个 PV。淘宝性能测试环境下，将这个概念做了延伸，系统真实处理的一个请求，视 为一个 PV。即，PV 的概念也适用于接口。 Peak PV 高峰Page View 即 PV 峰值，指一天中 PV 数达到的最高峰。 Concurrency并发 并发分为狭义和广义两类。 狭义的并发，即所有的用户在同一时刻做同一件事情或操作，这种操作一般针对同一类 型的业务，或者所有用户进行完全一样的操作，目的是测试数据库和程序对并发操作的处理。 广义的并发，即多个用户对系统发出了请求或者进行了操作，但是这些请求或操作可以 是不同的。对整个系统而言，仍然有很多用户同时进行操作。 狭义并发强调对系统的请求操作是完全相同的，多适用于性能测试、负载测试、压力测 试、稳定性测试场景；广义并发不限制对系统的请求操作，多适用于混合场景、稳定性测试 场景。 Scenario场景 性能测试过程中为了模拟真实用户的业务处理过程，在 LoadRunner 中构建的基于事务、 脚本、虚拟用户、运行设置、运行计划、监控、分析等的一系列动作的集合，称之为性能测 试场景。场景中包含了待执行脚本、脚本组、并发用户数、负载生成器、测试目标、测试执 行时的配置条件等。 Response Time响应时间 响应时间是指从客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结 果结束所经历的时间，响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组 成。 在性能测试结果分析中，性能场景中事务的响应时间请参阅图 4 所示，事务响应时间分 为事务最小响应时间、事务平均响应时间、事务最大响应时间。 图 4 Think Time思考时间 模拟正式用户在实际操作时的停顿间隔时间。 从业务的角度来讲，思考时间指的是用户在进行操作时，每个请求之间的间隔时间。 在测试脚本中，思考时间体现为脚本中两个请求语句之间的间隔时间。 TAOBAO PERF-TEST在脚本中的表现形式如下图 5 所示，加入的思考时间为 10 秒。 lr_think_time(10); lr_start_transaction("Limit Promotion"); 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_ID}geng", ENDITEM, "Name=auction_type", "Value=b", ENDITEM, "Name=title", "Value=2009-08-17 10:24 162", 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("Limit Promotion",LR_AUTO); 图 5 CPU资源 CPU 资源是指性能测试场景运行的这个时间段内，应用服务系统的 CPU 资源占用率。 CPU 资源是判断系统处理能力以及应用运行是否稳定的重要参数。应用服务系统可以包括 应用服务器、Web 服务器、数据库服务器等。 性能测试过程中，对 CPU 的监控以及分析报告、图表有 LoadRunner 自带监控分析、有 Linux 系统输出以及手工汇总、有第三方工具监控分析等。在此以 LR 监控分析图表（图 6）、 JVM 自带 CPU 监控图表（图 7）为例。 TAOBAO PERF-TEST图 6 图 7 Load负载 系统平均负载，被定义为在特定时间间隔内运行队列中的平均进程数。如果一个进程满 足以下条件则其就会位于运行队列中： 1. 它没有在等待 I/O 操作的结果。 2. 它没有主动进入等待状态（也就是没有调用“wait”）。 3. 没有被停止（例如：等待终止）。 性能测试结果分析 Load 分布如图 8 所示。 图 8 Std. Deviation标准差 TAOBAO PERF-TEST该标准差根据数理统计的概念得来，标准差越小，说明波动越小，系统越稳定，反之， 标准差越大，说明波动越大，系统越不稳定。包括响应时间标准差、TPS 标准差、Running Vuser 标准差、Load 标准差、CPU 资源利用率标准差、Web Resources 标准差等。举例响应时间标 准差，如图 9 所示，事务 SellerSaveItem 的响应时间为 0.043 秒，响应时间标准差为 0.01， 如图红色圈住所示。 图 9 性能测试模型 PV计算模型 为了让性能测试的 PV 计算更接近生产线真实情况，利用现有最新的数据得出性能测试 PV 的计算公式。 首先，通过http://monitor.taobao.com采集现有数据，图 10所示的是任意选择一天得到的 分布图， 6:00AM到次日的 6:00AM，共 24 小时。 10 图 10 经过长期监控，发现任何一天的分布图都与上图类似，故将这种分布视为整个淘宝网的 浏览量分布。 其次，进行数据统计：为了和目前真实情况更接近，选择最近一段时间的数据分布来做 样本，记录下系统能够监控到的最短时间间隔的数据，考察其值的走势，并且找出每一天的 最大值，抽样出每个时刻的值与当天最大值的比例，以此比例值的趋势，得出数据分布趋势， 如图 11 所示。 TAOBAO PERF-TEST监控系统最精确可以采集到每 3 分钟的数据，一天 24 小时可以采集到 480 个点。 1 0.8 0.6 0.4 0.2 0 图 11 采用微积分思想，将每个时间点视为一个矩形，可以通过求和的方式求出整个分布图的 面积，如图 12 所示。 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 17 图 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 是性能测试过程中的重要参考指标，在淘宝的性能测试 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 、执行、分析、评估等 各个阶段，TPS 都被看作是非常重要的一个环节；同时，在性能测试是否通过的衡量参数指 标里，它也有着举足轻重的影响。 众所周知，性能测试会依赖于特定的硬件、软件、应用服务、网络资源等，所以在性能 场景执行期间，TPS 可能会表现为稳定，或者波动，抑或遵循一定的上升或下降趋势。 TPS 表现轨迹可以总结为两大类： 一类是 TPS 有明显的大幅波动，不稳定。例如 TPS 轨迹缓慢下降，缓慢上升后骤降， 呈瀑布型，呈矩形，分时间段有规律的波动，无规律的波动等。这些 TPS 的波动轨迹反映 出被测试的性能点存在性能瓶颈，需要性能测试工程师与开发工程师查找性能瓶颈的原因。 另一类是 TPS 轨迹比较平稳，但是也存在波动现象。该类波动不明显，很难直接确定 是否存在性能瓶颈。如果单场景性能测试、稳定性测试结果显示 TPS 达到了期望值，是否 就确定 TPS 满足了期望呢？由于程序执行过程中服务器会有活动，造成 TPS 不可能是一条 完整的直线，那么多大的 TPS 波动范围认为是可以被接受的呢？ LoadRunner TPS 分析图中涉及到了 4 个重要的参数，最大值、平均值、最小值和标准 差值；平均值和标准差是衡量 TPS 是否稳定的重要因子。在此，我们强调一下 TPS 平均值 和 TPS 标准差的概念。 TPS 平均值是在场景执行过程中，被测系统在指定时间段内的平均每秒处理的事务数量。 TPS 标准差是根据数理统计的概念得来，反映被测系统的波动情况，标准差越小，说明波动 越小，系统越稳定，反之，标准差越大，说明波动越大，系统越不稳定。既然 HP Mercury 提供了这么好的数据给用户，那我们就要充分运用它。 目前淘宝性能测试，JAVA Web 和 JAVA 接口占了绝大部分，JAVA Web 和 JAVA 接口 在系统处理能力上有非常大的区别，如果将 JAVA Web 和 JAVA 接口分别做内部类比，由 于是不同的应用，每个性能点的 TPS 平均值、TPS 标准差也是差距非常大。因此，如果定 义一个 TPS 或者 TPS 标准差作为一个基线的话，不能应用到当前淘宝各类应用服务系统的 性能测试中。这也就说明了如果纯粹拿一个 TPS 平均值或者 TPS 标准差，不能完全说明 TPS 是否稳定。 而我们知道，标准差与平均数的比值称为离散系数或变异系数，变异系数可以消除单位 和（或）平均数不同对两个或多个资料变异程度比较的影响。标准变异系数是一组数据的变 异指标与其平均指标之比，它是一个相对变异指标。 因此，淘宝性能测试团队根据离散系数提出一个 TPS 波动范围的概念，定义为 TPS 标 准差除以 TPS 平均值，如公式 1 所示。 TPS标准差 t (TPS波动范围) = TPS平均值 ×100% 公式 1 由此来观察 TPS 标准差与 TPS 的比值 t，如果这个比值 t 超过了一定的范围，就确认这 个性能点的 TPS 不够稳定，也间接证明被测系统响应波动大而不满足性能期望。 性能测试团队搜集了以往 20 个典型项目中的 75 个性能场景，针对 JAVA Web 与 JAVA 接口的性能测试和稳定性测试，做了统计分析，得出可接受的 TPS 波动范围。如表 1 所示。 被测系统种类 测试是否通过 测试类型 超时概率 采样时间(s) 可接受的最大波 动范围 JAVA 接口 是 性能测试 低于万分之一 1 5%～8% JAVA 接口 是 稳定性测试 低于万分之一 60 5%～8% JAVA Web 是 性能测试 低于万分之一 1 4%～6% JAVA Web 是 稳定性测试 低于万分之一 60 4%～6% 建立 TPS 波动模型的出发点是为淘宝性能测试以及项目组建立一个可参考的标准，更 为有效的控制、降低项目上线后的风险。 有了这个统计模型，在性能测试衡量 TPS 是否稳定的时候，就有了一个参考依据，如 果 TPS 的波动范围高于表 1 所示，性能测试工程师就要配合项目组开发人员查找定位性能 瓶颈，并做进一步的性能优化。 注意：这个 TPS 波动模型是会随着淘宝各应用性能表现而相应变更的。当然，模型是 基于搜集来的数据、分析、论证得出，也不排除一些特殊的例子，在具体的性能测试应用中， 需要做出更为专业的评估。 共享中心性能测试模型 淘宝共享中心应用，管理着淘宝网核心数据和业务流程，直接与数据库或缓存服务器交 互，统一对全网上层 APP 提供服务。因此，它们扮演着极其重要的角色，其性能和稳定性 的要求都非常高。 为了更好的模拟共享中心的业务情况，在实践中探索出一个适用于当前现状的性能测试 模型。如图 13 所示。 图 13 该共享中心性能测试模型由三部分组成： 1. 性能测试工具（LoadRunner）。 2. Client 测试代码集。 3. 目标 Server。 该模型中，性能测试工具（LoadRunner）可通过 Windows Sockets 协议，调用 Client 测 试代码集中的测试场景，再由被调用测试场景对目标 Server 发起请求。三方共同完成整个 性能测试场景。 该模型有以下三个优点： 1. 通过水平扩展 Client，可以模拟任意多个 HSF 连接，最大限度模拟生产环境的真实 场景，解决以往模型只能模拟一个 HSF 连接的弊端。 2. Server 端作为承受压力端，也可以水平扩展，模拟多 Server 负载均衡、容灾等场景， 解决现有单台机器测试，扩展难度大的弊端。 3. LoadRunner 作为集中控制端，可以统一发送请求、统一收集数据，结果准确、可靠， 并可以通过代理进行扩展。 结论：从上述三点，可以看出，该模型不仅能真实的模拟淘宝网现有的调用架构，也能 灵活扩展，模拟出超大规模并发请求的场景。适用于目前共享中心的性能测试工作。 前端页面性能测试模型 随着大淘宝战略的开展，淘宝网的用户群体日益增大。与此同时，网站前端页面的性能 得到越来越多的关注，前端性能，已经成为不可或缺的部分。 为了更好、更快速的测试前端页面性能，为前端优化工作提供依据，定制了前端性能测 试模型。如图 14 所示。 图 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 个用户在使用，页面的 Page View 都 是可以统计到的。 因此，以 PV 为性能测试切入点，作为淘宝性能测试的突破口。通过这种方式，可 以将页面流量直接转化成 Page View，作为性能测试的预期目标，而削弱在线用户数和 并发用户数。得到 PV 数值之后，再通过 PV 计算模型、PV->TPS 转换模型，将它转化 成测试工具可以衡量的指标 TPS，从而使复杂的模型变得简单化、可衡量化。 4. 性能测试数据分为基础数据和业务数据两部分。 性能测试数据库和功能测试库相互独立。性能测试数据分为基础数据和业务数据两 部分。基础数据，指为了使表中的数据达到一定的数量级而填充的数据，目的是测试出 数据库索引是否足够优化、表空间、索引空间是否足够；业务数据，指为了使被测系统 能够按业务逻辑运行起来的数据，通俗而言，就是功能测试所使用的数据，目的是测试 出 SQL 语句是否足够优化、代码是否足够优化等。 5. 日志等级设置成 warn，避免大量打印 log 对性能测试结果的影响。 JAVA 日志，分为 info ,debug ,warn ,error 四个级别。 打印日志会消耗服务器的 IO，也会消耗硬盘存储空间。在性能测试过程中，如果频 繁打日志，会导致 IO 消耗大，从而消耗服务器的 CPU 资源；也会导致日志文件过大， 写入困难，程序执行速度变慢等问题。而 info 和 debug 两个级别，都会打印大量日志。 因此，性能测试过程中，选择将日志等级设置成 warn 级别，只打印出 warn 和 error 的 日志，即减少日志输入数量，又能监控到性能测试过程中出现的错误，一举两得。 6. 屏蔽 ESI 缓存，模拟最坏的情况。 ESI 缓存，是页面性能优化的手段之一。对于非频繁变化的数据，可以在容器中缓 存起来，提高读的性能，同时减轻数据库压力。ESI 缓存必须在数据被访问过后才会生 效，另外，缓存失效后需要重启缓存，即在系统刚发布、重新缓存过程中，用户访问速 度会变慢、数据库压力也会加大。 为了避免类似系统刚上线，数据库就受到 Load 过高，甚至面临崩溃的灾难。在性 能测试过程中，我们需要模拟没有 ESI 缓存的场景。 7. 先单场景，后混合场景，确保每个性能瓶颈都得到调优。 性能测试过程中，选择先执行单场景，后执行混合场景的策略。 单场景执行，可以详细测试到某个页面、某个接口等“单点”的性能，这种方式有 利于定位性能瓶颈，优化代码。对于使用 HSF 方式通信的淘宝来说，这样的针对性测试 效果非常显著。混合场景，在单场景都优化完成后，按照一定的比例对各种场景进行组 合，测试整个应用系统的总体性能表现。 其实，单场景和混合场景，两种都不可缺少。 8. 拆分问题，隔离分析，定位性能瓶颈。 性能测试过程中出现的小概率事件，往往隐藏着大的性能瓶颈。为了精确定位到瓶 颈，需要将各个应用，或者一个应用的各个环节进行拆分，逐渐隔离掉没有问题的部分， 然后在可能有问题的部分进行再排查，直到瓶颈定位到为止。 该过程类似于物理书中讲的电路图问题查找方法。 9. 根据性能测试通过标准，来判断被测性能点通过与否。 性能测试团队将公司对应用程序的要求、历史性能测试结果数据、生产线真实监控 结果，制定了淘宝网性能测试通过标准（详见性能测试通过标准）。从服务端性能、前 端性能、用户体验性能等多个维度界定，使通过标准更具科学性、指导性。 10. 性能瓶颈，录入 QC 域进行跟踪，对于不能在当前项目中解决的性能 bug，邀请专 家组进行风险评估。 使用 QC 维护、跟踪性能瓶颈。针对当前无法解决的瓶颈，在 QC 域中标注为 Later 状态，并请专家组进行风险评估，最终确定是否允许上线，将风险控制到最低水平。 性能测试评估 制定性能测试策略之后，如何开展性能测试工作呢？在实施性能测试之前，需要对被测 项目做相应的评估。实施前的评估，主要目的是明确是否需要做性能测试和确立性能点，明 确该测什么、期望值是多少。测试期望值也会根据情况评估，要求被测系统能满足将来一定 时间段的压力。性能测试评估分为测试前的评估和测试后的评估。这里重点阐述测试前的评 估，测试后的评估在“性能测试通过标准”章节进行描述。 主要从以下 4 个维度进行测试前的评估： 1. 关键业务。 2. 日 PV 量。 3. 逻辑复杂度。 4. 运营推广计划。 关键业务 首要维度，是确定被测项目是否属于关键业务，有哪些主要的业务逻辑点，特别是跟买 家、卖家息息相关的功能点。例如，hesper 系统，用于展现商品 list，供用户查询商品，它 具有商品搜索、商品分类、SPU 展现、类目排序、相关搜索等功能。通过评估，从中筛选 出商品搜索、商品分类、SPU 展现这三个主要业务涉及的功能。 如果项目（或功能点）不属于关键业务（或关键业务点），则可转入第二、三、四个维 度进行评估。 日PV量 第二个维度，是界定被测项目各功能点的 PV 量（或者日请求量）。如果 PV 量很高， 系统压力很大，而且又是关键业务，该项目需要做性能测试；而且其关键业务点，可以被确 定为性能点。例如，上述例子中的商品搜索、商品分类。 如果 PV 量不高，系统压力不大，但却是关键业务点，则依据第三个或第四个维度来判 断。 逻辑复杂度 第三个维度，是判定被测项目各功能点的逻辑复杂度。如果一个主要业务的 PV 量不高， 但是逻辑很复杂，则也需要通过性能测试。原因是，在 HSF 方式的调用中，当某一个环节 响应较慢，就会影响到其它环节，造成雪崩效应。例如，消保项目中的加入消保业务，其 PV 量很低，但是需要多达十几个判断条件，频繁访问数据库。则该功能点需要作为一个性 能点进行测试。 运营推广计划 第四个维度，是根据运营的推广计划来判定待测系统未来的压力。未雨绸缪、防患于未 然、降低运营风险是性能测试的主要目标。被测系统的性能不仅能满足当前压力，更需要满 足未来一定时间段内的压力。因此，事先了解运营推广计划，对性能点的制定有很大的作用。 例如，运营计划做活动，要求系统每天能支撑多少 PV、多少 UV，或者一个季度后，需要 能支撑多大的访问量等等数据。 当新项目（或功能点）属于运营重点推广计划范畴之内，则该项目（或功能点）也需要 做性能测试。 其它 以上 4 个评估维护，是相辅相成、环环相扣的，它们合成一个维度集。在实际工作中， 应该具体问题具体分析。例如，当一个功能点不满足以上 4 个维度，但又属于内存高消耗、 CPU 高消耗时，也可列入性能测试点行列。 性能测试类型 性能测试压力变化模型 随着单位时间流量的不断增长，被测系统的压力不断增大，服务器资源会不断被消耗， TPS 值会因为这些因素而发生变化，而且符合一定的规律。淘宝网性能测试压力变化模型如 图 15 所示。 19 图中： a 点：性能期望值 图 15 b 点：高于期望，系统资源处于临界点 c 点：高于期望，拐点 d 点：超过负载，系统崩溃 性能测试类型 由上述压力变化模型，将淘宝网性能测试分成狭义的 4 种类型： 1. 性能测试。 2. 负载测试。 3. 压力测试。 4. 稳定性测试。 性能测试 a 点到 b 点之间的系统性能 定义：狭义的性能测试，是指以性能预期目标为前提，对系统不断施加压力，验证系统 在资源可接受范围内，是否能达到性能预期。 运用场景：此类型的测试目前最常见。每个项目的性能点，都需要做性能测试。 负载测试 b 点的系统性能 定义：狭义的负载测试，是指对系统不断地增加压力或增加一定压力下的持续时间，直 到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等。 运用场景：此类型的测试目前运用得比较少。一般情况下，是以服务器资源安全临界值 为界限的测试。如果要模拟某个应用在指定服务器上最大且安全的负载量，则属于负载测试。 压力测试 b 点到 d 点之间 定义：狭义的压力测试，是指超过安全负载的情况下，对系统不断施加压力，是通过确 定一个系统的瓶颈或不能接收用户请求的性能点，来获得系统能提供的最大服务级别的测试。 运用场景：此类型的测试目前运用得比较少。但对于大型的共享中心或者核心的应用， 也会用到。 稳定性测试 a 点到 b 点之间 定义：狭义的稳定性测试，是指被测试系统在特定硬件、软件、网络环境条件下，给系 统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定，一般稳定性测试 时间为 n*12 小时。 运用场景：此类型的测试目前也最常见，针对需要长时间稳定运行的性能点，需要执行 稳定性测试。往往在一个项目的性能测试过程中，会划分出优先级较高的性能点，做稳定性 测试。例如：宝贝详情页面等等。 性能测试执行方法 性能测试通常采用先单场景，后混合场景的执行方法。 单场景 针对单个性能测试点，构建一个性能测试场景，而进行的性能测试。单场景适用于性能 测试、负载测试、压力测试、稳定性测试。 案例 1. 无线彩票项目，有彩票购买，彩票详情，彩票查询 3 个性能点；性能测试工程 师可以根据这三个性能点，在性能测试设计时，分别制定测试策略，创建性能、负载、压力、 稳定性测试场景。从而有效模拟应用服务系统上到生产线上后的运行情况。提前发现暴露的 性能问题或者隐藏的性能隐患，有效的控制风险。 混合场景 为了尽量模拟生产线上运行的业务压力或用户使用场景，测试系统的整体性能是否满足 性能需求，把经过一定规则筛选的性能测试点，按照合乎实际逻辑的虚拟用户请求、并发， 组合成一个混合场景。 混合场景的特征，通常包含两个或者两个以上的脚本组，执行时间较长。混合场景通常 在稳定性测试、负载测试中使用。 案例 1. 限时打折项目，用户登录状态点击加入购物车、用户登录状态打开我的购物车 列表、用户登录状态立即购买创建订单、用户登录状态购物车点击确认订单这 4 个性能点， 是用户购买时的几个主要操作，在模拟真实业务时，就需要把该项目中的几个性能点有机组 合成一个混合场景，进行更加有效模拟生产线上的性能测试。 案例 2. 无线彩票项目，有彩票购买，彩票详情，彩票查询 3 个性能点，这 3 个性能点 在线上互不干扰运行，用户在购买前后可以查看彩票详情，购买前后也可以查询彩票相关信 息；为了做到准确模拟，混合场景中把各性能点脚本 group 组合成为一个基于虚拟用户、运 行设置、运行计划、监控资源、日志输出等的性能场景，进行规范性更强、更加切合实际的 性能测试。 性能监控 性能监控需要实时观察性能测试过程中各项指标是否正常，包括应用服务器、数据库、 中间件、网络等方面，保证测试前提，记录测试数据，输出监控结果。更重要的是，监控的 过程是发现系统瓶颈的过程，是性能分析、性能通过与否、性能报告输出等环节的基础和依 赖。 监控需要使用不同的工具，结合系统日志、应用和服务器所反映的多项指标，记录监控 数据。以下阐述了监控指标、监控工具和监控步骤等三个部分内容。 监控指标 性能测试通常需要监控的指标包括： 1. 服务器：Linux 应用服务器。 具体包括 CPU、Memory、Load、I/O、Disk 等。 2. 数据库：1.Mysql 2.Oracle。 具体包括缓存命中、索引、单条 SQL 性能、数据库线程数、数据池连接数等。 3. 中间件：1.Jboss 2. Apache。 具体包括线程数、连接数、日志输出等。 4. 网络。 具体包括防火墙、网卡、网线、吞吐量、吞吐率等。 5. 应用服务。 具体包括 JVM 内存使用和回收、JAVA 内存使用、Full GC 频率、JAVA 类装入和 卸载、日志、线程运行状态（阻塞、等待、正常运行）等。 6. 监控工具（LoadRunner）。 具体包括用户执行情况、场景状态、事务响应时间、TPS、Load、CPU 分析图表等。 7. 测试机资源。 20 具体包括 CPU、Memory、网络、日志输出、磁盘空间、负载生成器评估等。 监控工具 性能测试通常采用下列工具进行监控： 1. Profiler Profiler 是一个时间统计程序，他通过在程序中埋点，将埋点时间记录入线程变量中以 实现隔离，最后 dump 出结果，得出埋点时间树。。 具体请见 淘宝内网 “时间监 控 ——Profiler 使用方 法”这篇 文章。访 问链 接http://www.taobao.ali.com/chanpin/km/architect/Wiki/ 时间监控--Profiler 使用方法.aspx可获 取。 2. JStat Jstat 是 JDK 自带的一个轻量级小工具。全称“Java Virtual Machine statistics monitoring tool”，它位于 java 的 bin 目录下，它主要利用了 JVM 内建的指令对 Java 应用程序的资源和 性能进行实时的命令行的监控，包括了对 Heap size 和垃圾回收状况的监控。可见，Jstat 是 轻量级的、专门针对 JVM 的工具，很实用。 具体帮助支持文档请参阅性能测试Jstat使用方法总 结：http://www.taobao.ali.com/chanpin/km/test/DocLib/性能测试辅助工具－Jstat的使用方 法.aspx 或者参考 SUN 官网的技术文档： http://Java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstat.html http://java.sun.com/javase/6/docs/technotes/tools/share/jstat.html 3. JConsole JConsole 是一个用 JAVA 写的 GUI 程序，用来监控 VM，并可监控远程的 VM，易用且 功能强大。具体可监控 JAVA 内存、JAVA CPU 使用率、线程执行情况、加载类概况等，JConsole 需要在 JVM 参数中配置端口才能使用。由于是 GUI 程序，界面可视化，这里就不做详细介 绍，具体帮助支持文档请参阅性能测试 JConsole 使用方法总结： http://www.taobao.ali.com/chanpin/km/test/DocLib/性能测试辅助工具－JConsole的使用 方法.aspx 或者参考 SUN 官网的技术文档： http://Java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html http://Java.sun.com/javase/6/docs/technotes/tools/share/jconsole.html 4. JMap Jmap 是一个可以输出所有内存对象的工具，甚至可以将 VM 中的 heap 以二进制输出 成文本。可以监控 JAVA 程序是否有内存泄漏，需要配合 eclipse 插件 MemoryAnalyzer 来使 用。 使用方法：上 jmap -histo PID。如果连用 SHELL jmap -histo PID > a.log 可以将其保存 到文本中（windows 下也可以使用），在一段时间后，使用文本对比工具，可以对比出 GC 回收了哪些对象。jmap -dump:format=b,file=f1 PID 可以将该 PID 进程的 heap 内存输出到 f1 文件里，并使用 MemoryAnalyzer 工具查看。 具体帮助文档请参阅性能测试 JMap 使用方法总结： http://www.taobao.ali.com/chanpin/km/test/DocLib/ 性 能测试辅助工具－JMap 的使用方 法.aspx 或者参考 SUN 官网的技术文档： 29 http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jmap.html http://java.sun.com/javase/6/docs/technotes/tools/share/jmap.html 5. JProfiler JProfiler 分析工具是目前功能相对比较全的 JAVA 剖析工具（profiler），专门用于分析 J2SE 和 J2EE 应用程式。它可以详细的剖析 CPU、线程和内存的使用信息。JProfiler 可提供 许多 IDE 整合和应用服务器整合功能。JProfiler 直观式的界面让你可以方便的找到性能瓶颈、 抓住内存泄漏(memory leaks)、并解决多线程的问题。可以对内存的 GC 的资源回收器做深 入的分析，可以轻易找出内存泄漏；JVM 内存的快照（snapshot）模式可以让未被引用 （reference）的对象、稍微被引用的对象、或在终结（finalization）序列的对象都清晰地呈 现出来。 官方下载地址： http://www.ej-technologies.com/index.html 以上地址可以下载到最新的试用版本，通过邮件申请一个十天的试用注册码。 此外，可通过以下性能测试的知识分享链接，了解以上功能的详细介绍： http://www.taobao.ali.com/chanpin/km/test/DocLib/性能测试协助工 具%20-%20Jprofiler%20foundation%20Summary.aspx 关于 JProfiler 的简单使用过程包括（具体方法可参考官方文档）：客户端 JProfiler 安装、 服务器端 JProfiler 安装、客户端连接配置（建立远程服务连接配置信息）、服务器端的配置 （包括修改环境变量、应用服务启动参数等）。 按照以上步骤便可以使用JProfiler的客户端软件监控远程的JAVA应用。详细的使用方法 可参考性能测试Jprofiler使用方法总结： http://www.taobao.ali.com/chanpin/km/test/DocLib/性能测试协助工具%20-%20JProfiler调 优实例.aspx 此外，如何快速搭建 JProfiler 监控，可参阅淘宝内网的性能测试知识沉淀： http://www.taobao.ali.com/chanpin/km/test/Lists/List8/Flat.aspx?RootFolder=%2fchanpin% 2fkm%2ftest%2fLists%2fList8%2f%e5%88%86%e4%ba%ab%e5%a6%82%e4%bd%95%e5%bf %ab%e9%80%9f%e6%90%ad%e5%bb%baJProfiler%e7%9a%84%e7%9b%91%e6%8e%a7&Fol derCTID=0x01200200256EA63523F035408D66B51479694109&TopicsView=http%3A%2F%2 Fwww%2Etaobao%2Eali%2Ecom%2Fchanpin%2Fkm%2Ftest%2FLists%2FList8%2FAllItems% 2Easpx 6. Nmon Nmon 是一种在 AIX 与各种 Linux 操作系统上广泛使用的监控与分析工具，相对于系统 资源上的一些监控工具来说，Nmon 所记录的信息是比较全面的，它能在系统运行过程中实 时地捕捉系统资源的使用情况，并且能输出结果到文件中，然后通过 nmon_analyzer 工具产 生数据文件和图形化结果，方便用户分析服务器资源和寻找问题。 Nmon 的特点包括： 1) 全面的信息统计 包括 CPU 使用率、内存使用情况、内核统计信息和运行队列信息、磁盘 I/O 速度、 传输和读/写比率、网络 I/O 速度、传输和读/写比率等等 2) 简单方便使用 支持各种 Linux 操作系统和 aix。只需把可执行文件拷贝到服务器上，便可以实现 全面的信息监控，并且能够在一个屏幕上查看大量的信息。 3) 完全免费 尽管 IBM 没有提供对该工具的正式支持，并且在使用它的时候必须自己承担相应 的风险，但是您可以从中获得大量有价值的性能统计信息。 可以从 IBM Wiki 的网站下载到最新的 Nmon 及其工具： http://www-941.haw.ibm.com/collaboration/wiki/display/WikiPtype/nmon Nmon 使用方法： 解压->上传服务器->赋于可执行的权限->直接运行 ./nmon (修改名称)。分别输入 c、t、 n、m，可以了解系统 CPU、内存、消耗资源最高的线程的使用情况。首页会有各种帮助的 参数命令。 Nmon 数据采集： 命令./nmon -f -t -r test -s 30 -c 180 生成 nmon 分析文件。（注：-s 30 每 30 秒执行一次 数据采集； -c 180 共采集 180 次）。更多的参数可参照该命令的帮助文档。 Nmon 数据分析： 使用 nmon_analyser 工具，调整 excel 宏安全设置，打开.nmon 文件，便可以生成附件 report 格式的 excel 文件。 7. Valgrind Valgrind 是一款基于模拟 Linux 下的程序调试器和剖析器的软件套件，用于监控程序是 否存在内存泄露。Valgrind 可以支持很多工具：Memcheck，Addrcheck，Cachegrind，Helgrind 和 Callgrind 等，即可以监控内存分配、内存地址分配、缓存分配等。在监控结果中，以疑 似泄露、真实泄露形式提供报表，并打印出泄露的字节数。使用者可以很清晰的定位和识别 泄露的程序段，便于调优。 Valgrind 适用于监控 C/C++程序，基于 Linux 环境。 Valgrind 的使用方法总结： 使用 Valgrind 启动被测程序，并指明监控的工具名、监控的类别、选项、结果输出文件 名即可。如：valgrind --tool=memcheck --leak-check=yes --log-file=mem.log ./post.sh >logfile6 或者参考 Valgrind 官网的技术文档： http://valgrind.org/docs/manual/manual.html http://valgrind.org/docs/manual/faq.html 8. VMmap 和 ApplicationVerifier VMmap 和 ApplicationVerifier 是两款优秀的基于 windows 环境的内存监控工具。淘宝使 用较少，在此不做详细介绍。 这两个工具用于监控 C/C++程序是否存在内存泄漏，基于 windows 环境。 监控步骤 1. 确定需要监控的目标，即监控对象是什么。 2. 确定监控和分析所需信息（可以采用 CheckList 模版法，列出所需要监控的指标，信 息）。 3. 确定监控所使用的工具（根据性能点的类型，以及需要关注的性能指标来确定。 4. 收集监控所得数据（可以采用日志监控＋辅助工具法，收集所需监控数据）。 5. 分析所采集的数据，定位性能瓶颈。 6. 性能调优。 7. 循环以上步骤，直到调优完毕。 性能分析 淘宝网已经跨入分布式时代，分布式的到来，也给性能测试增加了难度。性能测试分析 原则和分析方法，显得尤为重要。以下阐述性能测试分析原则、分析信息来源、分析标准和 分析工具。 分析原则 在分布式架构下，性能瓶颈分析也变得相对困难。针对不同的应用系统、不同的测试目 标、不同的性能关注点，根据性能指标的表现，采用“拆分问题，隔离分析”的方法进行分 析，即逐步定位、从外到内、从表及里、逐层分解、隔离排除。 淘宝性能分析，可按以下顺序： 中间件瓶颈（apache/jboss 参数配置、数据库参数配置）-> 应用服务的 debug log -> 应 用服务的 filter log -> 本应用的性能瓶颈（代码、SQL 语句、索引、业务逻辑、线程池设置、 算法）-> 服务提供者的性能瓶颈 -> 相关联的底层存储应用的性能瓶颈 注：以上是比较通用的分析过程，具体性能测试查找瓶颈过程中，需要具体问题具体分 析。 分析信息来源 1. 监控工具所采集的信息。 包括 LoadRunner 和“监控工具”部分描述的工具。具体为：TPS、响应时间、用户 并发数、JVM 内存、Full GC 频率、CPU 利用率、Load 等。 2. 应用服务器的日志。 包括本应用和远程应用的错误日志、超时日志等。 3. 项目配合人员所提供的信息。 包括 DBA 提供的数据库监控信息、开发人员提供的代码逻辑信息、OPS 提供的配 置专业指导信息。 分析标准 通过性能指标的表现形式，分析性能是否稳定。比如： 1. 响应时间是否符合性能预期，表现是否稳定。 2. 应用日志中，超时的概率，是否在可接受的范围之内。 3. TPS 维持在多大的范围内，是否有波形出现，标准差有多少，是否符合预期。 4. 服务器 CPU、内存、Load 是否在合理的范围内，等等。 分析标准参考“性能测试通过标准”的各项指标进行。 分析工具 对于部分性能指标，可借助自动分析工具，统计出数据的总体趋势： 1. LoadRunner analysis 分析 LoadRunner analysis 是 LoadRunner 的一个部件，用于将运行过程中所采集到的数 据生成报表，主要用于采集 TPS、响应时间、服务器资源使用情况等变化趋势。如图 16 所示。 2. 日志分析工具分析 图 16 在性能测试过程中，需要对应用的超时日志进行分析，从而得出超时概率，用于判 断超时是否在可以接受的范围内，并定位引起超时的原因。 淘宝性能测试团队针对目前最主要的 Profiler 格式的超时日志，用 ruby 语言自主开 发了日志分析工具，实现在 tWork 执行日志分析和展示分析结果。分析结果包括：日 志的总体统计信息、平均响应时间、区间分布、耗时排名。同时，结果展示结合了图 表，使得对日志分析更加直观、方便。 日志分析结果的三个维度： 1) 平均响应时间：统计日志中同一个访问请求的每个方法或模板的平均响应时间。 通过该维度，可以直观的看出，测试中响应时间消耗较大的方法或模板。如图 17 所示。 2) 区间分布：按照响应时间划分出的 9 个区间，统计每个方法或模板的响应时间落入 该区间的次数。 通过该维度，可以直观的看出，方法或模版的响应时间在大多数情况下落在哪个区 间内，从而判断该响应时间是否正常。如图 17 所示。 图 17 3) 耗时排名：统计每次请求中响应时间最大的 5 个方法或模板出现的次数。 通过该维度，可以直观的看出，所有的超时请求主要是由于哪些方法或模板引起的。 如图 18 所示。 3. Memory Analyzer 分析 图 18 TAOBAO PERF-TESTMemory Analyzer 工具可以解析 Jmap dump 出来的内存信息，查找是否有内存泄漏。 具体请参阅eclipse官网MAT部分：http://www.eclipse.org/mat/ 4. Nmon_analyzer 分析 Nmon 工具可以采集服务器的资源信息。列出 CPU、MEM、网络、I/O 等资源指标 的使用情况。它是以 Nmon 性能工具生成的文件作为输入，然后将它们转换为 Microsoft Excel 电子表格，并自动地生成相应的图形。 该工具的作用： nmon_analyzer 工具可以帮助对通过 Nmon 性能工具捕获的性能数据进行分析。它 允许性能测试工程师完成下列任务： 1) 以电子表格的形式查看相应的数据 ； 2) 消除“错误的”数据 ； 3) 生成向客户进行演示的图形，如图 19 所示。 性能测试通过标准 图 19 性能测试从需求、设计、准备、执行到分析，最后需要判断性能测试是否通过。性能测 试工程师最终需要考虑很多因素，判断的标准相应的也会有多个维度。 此处，引入超时阈值和超时概率两个概念。超时阈值，是指在框架模板中定义的超时时 间，当服务器响应超过该定义值时，被测程序仍然响应请求，同时 Profiler 会打印超时日志。 超时概率，是指超时次数除以总请求次数所得的值。 由上述概念可以得出，此处的超时不等于请求失败。 1. 性能测试通过标准 性能测试通过标准包括服务端性能、前端性能和用户体验性能，通过标准如表 2 所示。 类别 判断维度 不通过 通过 备注 服 务 超时概率 大于万分之一 小于万分之一 1、性能测试团队根据通 错误概率 大于万分之一 小于万分之一 TPS 小于期望高峰值 大于期望高峰值 TPS 波动范围 见TPS波动模型 见TPS波动模型 过标准，判定被测性能点 CPU 利用率 大于 75% 小于 75% 端 性 不通过，而 PM、PDM 认 响应时间 大于期望时间 小于期望时间 能 为可以通过时，需要进行 Load 平均每核 CPU 的 Load 大于 1 平均每核 CPU 的 Load 小于 1 沟通。沟通以会议形式， 由专家组来评判。 JVM 内存使用率 大于 80% 小于 80% 2、页面大小包括 js/css/ 图片等资源。 Full GC 频率 平均 小于半小 时 1 次 平均大于半小时 1 次 3、最佳情况下，页面下 载时间小于 2s。 前 端 页 面 性能 YSlow 评定 YSlow 评定为 C 级 以下 YSlow 评定 为 C 级，或 C 级以上 用 户 体 验 性能 页面大小 页面大于 800k 页面小于 800k 页面响应 1M 带宽，大于 8s 1M 带宽，小于 8s 表 2 2. Profiler 超时阈值设定 淘宝性能测试团队联合架构师和各共享中心负责人，定义了不同应用的 Profiler 超时阈 值。目前已经界定出的超时阈值如表 3 所示。 超时阈值定义 页面 http 响应 时间 页面 http 响应时间 500ms UIC 响应时间 单条接口（缓存） 20ms 批量接口（缓存） 50ms UserPromotedService 接口 80ms IC 响应时间 提交操作的接口 120ms 单条查询类的接口 50ms 批量查询类的接口 100ms 有缓存的接口 30ms TC 响应时间 不与支付宝交互的接口 100ms 与支付宝交互的接口（mock 支付宝） 100ms SC 响应时间 一般的接口 20ms 相册相关接口 450ms 保存店铺装修接口 400ms 销售统计相关接口 150ms 表3 性能测试通过标准，是判断性能测试通过与否的最全面的参考依据。随着淘宝性能测试 的发展，这些标准也会随之相应改动，要求会越来越严格。 性能测试流程 性能测试流程图 性能测试是一个系统工程，涉及到 PDM、PM、PTM、性能测试工程师、DBA、SCM、 OPS 等多个角色。从性能测试申请，到性能测试设计、性能测试环境、性能测试数据、性 能测试执行、性能测试调优，都离不开这些角色的相互配合，共同协助。因此，淘宝网确立 了一整套性能测试流程，采取团队合作的方式，降低沟通成本，提高工作效率。 性能测试流程图如图 20 所示。 性能测试流程主要活动 图 20 测试流程中的主要活动描述如下： 1. 申请性能测试资源：在项目立项前的技术方案阶段，PTM/PM 和 PDM 评估出是否 需要做性能测试。如果需要，则 PTM/PM 通过访问 tWork 性能中心，向性能测试 小组申请性能测试资源。 2. 批准资源：性能测试小组根据申请表进行批准资源。 3. 制定性能测试计划：性能测试工程师根据项目（日常）计划和功能测试计划，制定 性能测试计划。 4. 编写性能测试设计方案：性能测试工程师在 UC 评审之后，邀请 PM、PDM、测试 负责人，一起细化性能测试需求，编写性能测试方案。 5. 评审性能测试设计方案：性能测试工程师，组织性能测试设计方案评审会议，邀请 PM、系统设计人员、PDM、测试负责人、DBA、SCM、OPS 共同参与。其中，SCM 和 OPS 为可选人员。评审主要是针对测试目标、测试策略和测试数据进行确认， 并提出改进意见，达成一致。最终的性能测试设计方案，由性能测试工程师上传。 6. 提交代码、配合搭建环境、配合数据准备：性能测试执行前 3 个工作日，性能测试 工程师以邮件的方式，将环境搭建需求提交给 SCM，并将收集到的服务器相关需 求提交给 SCM。SCM 负责搭建性能测试环境。PM 负责提交代码并通知 SCM 进行 切换。同时 DBA 根据性能测试设计要求，准备测试数据。即搭建环境和准备数据 是并行环节。搭建完成后，性能测试工程师负责验证环境和数据。性能测试工程师 同时开发性能测试脚本，并调试通过。该步骤需要 PM 的密切配合。 7. 执行性能测试（性能测试工程师）：第一轮功能测试通过之后，性能测试工程师执 行性能测试，执行脚本需要符合规范。分析性能测试结果，找到性能瓶颈，配合开 发人员进行性能调优。性能测试工程师每天产出性能测试日报。性能测试工程师判 断性能测试结果是否满足期望。执行过程中，通知 DBA 监控数据库和 SQL 执行情 况，并做统计。 8. 性能调优：PM、性能测试工程师、DBA、SCM、OPS 共同参与性能测试调优方案 的制定工作。其中，OPS、DBA 为可选角色（当有数据库问题时，PM 邀请 DBA 参与。当有隐蔽的系统问题时，PM 邀请 OPS 参与）。代码的调优工作，由 PM 或 者 PM 指定开发人员完成。该阶段，SCM 负责维护性能测试环境。 9. 编写性能测试报告：性能测试工程师编写性能测试报告，阐明性能测试目标、性能 测试环境、性能测试数据构造规则、性能测试策略、性能测试结果、性能测试调优 说明、性能测试过程中遇到的问题和解决办法等。 10. 录入基线库：性能测试工程师将测试结果录入性能测试基线库，包括性能测试结果 数据、性能测试瓶颈和调优方案。 11. 知识沉淀：性能测试工程师将测试过程中遇到的问题，包括代码瓶颈、配置项问题、 数据问题和沟通问题，以及解决办法或解决方案，进行知识沉淀。 性能测试文件模版 为了配合性能测试流程，更好的开展测试工作。性能测试开发多个模版，用于指导和规 范文档编写，提高效率。当前使用的模版和规范已经由 SQA 在公司内发布，包括： 1. 性能测试资源申请模版 下载地址： http://confluence.taobao.ali.com:8080/pages/viewpage.action?pageId=697 下的测试阶 段，目前性能测试资源申请在tWork上填写提交，地址 是http://twork.taobao.net/perf/perf_applications。 2. 性能测试设计方案模版 下载地址： http://confluence.taobao.ali.com:8080/pages/viewpage.action?pageId=697下的测试阶段。 3. 性能测试报告模版 下载地址： http://confluence.taobao.ali.com:8080/pages/viewpage.action?pageId=697下的测试阶段。 4. 性能测试日报模版 邮件版，未提供下载链接。 5. 淘宝性能测试脚本和场景制作规范 下载地址： http://confluence.taobao.ali.com:8080/pages/viewpage.action?pageId=697下的测试阶段。 结束语 以上部分的介绍，详细的描述了性能测试指标的概念、性能测试 PV 模型、PV->TPS 转 换模型、TPS 波动模型、性能测试策略、性能测试评估、性能测试类型、性能测试执行方法、 性能监控、性能分析、性能测试通过标准、性能测试流程和文件模板等几个内容。 30 此外，在每部分的内容当中，适当的增加了 案例分析 安全事故典型案例分析生活中谈判案例分析管理沟通的案例分析股改案例分析刑法学案例分析 、链接、代码和图表解释，以便大 家能更好的理解性能测试过程，理解性能测试的理论。 最后，希望本白皮书能够更好的规范性能测试理论、以及指导性能测试协作团队更好的 完成性能测试工作，达到最佳、最优的进行性能测试的目的，降低沟通成本，提高测试效率。 让更多的淘宝同事分享性能测试知识、提高性能测试水平，更好的参与到性能测试中来。 参考文献 【1】 LoadRunner 8.1 User Manual. Mercury Interactive , 2006 【2】 Fundamentals of LoadRunner 8.1. Mercury Interactive , 2005 【3】 Mercury Load Runner 8.1 教程. Mercury Interactive , 2006 【4】 于涌 软件性能测试与 LoadRunner 实战. 北京：人民邮电出版社出版 【5】 姜艳，于波 Load Runner 性能测试应用. 北京：电子工业出版社 【6】 陈绍英，夏海涛，金成姬. Web 性能测试实践【M】. 北京：电子工业出版社 32 版本更新说明 本次 V1.0 版，在原 V0.8 版本基础上做了新增和丰富。具体如下： 新增： 1) 序言 2) 增加共享中心性能测试模型 3) 增加前端页面性能测试模型 丰富： 1) PV 计算模型――添加结论，使分析更通俗易懂 2) PV->TPS 转换模型――添加结论，使分析更通俗易懂 V1.0 旨在使白皮书走向完善化、完整化。主要添加了性能测试过程中的两个重要的模 型，并丰富 PV 计算模型、PV->TPS 转换模型，使整个白皮书更加通俗易懂。性能测试白皮 书已经日趋完善，基本囊括性能测试目前的所有标准和精华。 作者介绍 淘宝性能测试团队成员，将性能测试工作实践升华、提炼之后，编写成白皮书。自从白 皮书的概念提出以来，各成员都参与了研究、编写、修订工作。在此，感谢每位成员的辛苦 付出。作者介绍如下： 》 丘虚 总体界定了白皮书的范围，规划编写资源、提供宏观的修订意见。 》 悟石 协调整体编写和修订工作。主要负责编写 PV->TPS 转换模型、共享中心性能测试模型、 前端页面性能测试模型、性能测试策略、性能测试评估、性能测试类型、性能测试通过标准、 性能测试流程和性能测试文件模版，参与编写性能监控、性能分析、TPS 波动模型。 》 耿电 提出白皮书概念。主要负责编写性能测试指标、TPS 波动模型、性能测试执行方法，参 与编写性能分析、性能监控。 》 元壮 数学建模。主要负责编写 PV 计算模型、建模，参与 TPS 波动模型建模。 》 云帅 主要负责编写性能监控和性能分析，参与编写 TPS 波动模型。 》 词馨 主要负责编写日志分析工具，参与编写性能测试流程主要活动。 》 武彻、冷之 参与白皮书校验工作。 在介绍作者的同时，更要特别感谢为白皮书 review 的测试部门的其它同学们。本次虽 为 1.0 版本，考虑到有新的内容推出，不免有错误或不全之处，欢迎阅读的同学们给出宝贵 的建议，以便持续改进和完善。