淘宝网的性能测试自动化平台具备了分布式、高并发、低成本、可扩展等特性的性能测试平台工具，它包括性能项目管理、环境管理、脚本管理、场景管理、任务管理、监控管理、结果管理等模块，以及前端性能测试模块、性能测试报告模块、性能缺陷模块、和性能基线模块等，后台还有完善的分布式压测引擎管理平台。
本文结合性能测试在企业云架构上的应用案例，介绍淘宝网的性能测试从无到有经历的阶段，同时介绍自主研发的自动化性能测试平台诞生的条件和过程，解析如何使用性能测试的方法保障企业应用的性能，同时如何构建一个性能自动化测试平台。
（全文共9698字预计阅读时长：12分钟）
淘宝网性能测试团队成立于2009年1月，当时团队只有2个人。从那个时候起，团队成员便开始参与或负责淘宝网的核心技术架构变革的性能测试工作，当时的“五彩石”项目就是团队的一个关键里程碑，它代表了性能测试团队的第一次大规模实践和产出。
团队刚好经历淘宝网的技术由Java初期时代到大规模分布式系统时代，也经历了在这个时代所产生的问题。
性能测试团队发展至今，其成长过程大致可分为业务发展、平台发展和产品上云三个阶段。
淘宝网性能测试的演变
淘宝网性能测试的发展过程如表1所示。
表1淘宝网性能测试的发展
●1.1业务发展阶段（2016年1月到2011年8月）
它是性能测试团队成长的基础，是性能团队、积累和总结的过程。这个阶段在大量的做项目和日常的业务测试，每个成员都同时承担着超过5条产品线的项目性能工作，同时测试的项目最多时可达十余个。在这种高强度高压力的业务测试历练中，团队的每一位成员都拥有了丰富的业务测试经验，对今后团队的发展、技术发展和平台发展都起到了重要的基石作用。
在这个团队雏形时期，产出了具备一定参考价值的《性能测试白皮书》、《性能测试宝典》、《性能测试大型项目压测模型》、《性能测试常用工具和使用方法》、《性能测试流程》等文档；同时也产出了性能测试的各种方案，包括《性能测试设计方案模板》、《性能环境守则》、《性能环境目录规范》、《性能测试报告模板》、《性能测试过程文件》、《性能测试环境搭建规程》、《性能测试流程图》、《性能测试日报模板》、《性能测试资源申请模板》等，这些文档和方案直到现在对于业界新人仍然起到了入门、学习和引导的作用。
●1.2平台发展阶段（2011年9月到2013年8月）
它是性能测试团队创新的阶段和过程。业务发展到一定阶段，必然需要产品、平台的支持才可以走得更远，更加专业，2011年的8月，团队的TL意识到以下几点：
在当时的系统工具和平台部门下，我们这样一个专业的性能测试团队，却没有一个适合自己、适合淘宝的性能测试工具和平台，这种情况的改变迫在眉睫，去除Loadrunner更是当务之急。
在这个阶段，我们为了解决性能资源申请和透明化、流程化的瓶颈，产出了“T-work性能中心”；为了解决线上线下性能对比的问题，和核心团队合作，开发了“线上线下跟踪体系平台”、“线上线下容量评估平台”，也就是CSP的前身；紧接着团队自己开发了“性能自动化测试平台-PAP”当时还是以Tsung为主性能测试压测引擎，在平台积累了一定量的用户以后，我们继续开发了核心压测引擎“分布式压测引擎-Trunner”、“压测引擎管理平台-Trunner-console”、“前端性能测试平台”等。
同时我们除了前端性能测试，也开始着手研究客户端性能测试方法（旺旺）、无线性能测试方法等，使得性能测试在支持阿里集团各BU上更加专业、更加广泛，且朝着体系化、平台化和系统化的方向发展。
●1.3共建和云测试发展阶段（2013年9月至今）
在这个阶段，我们团队邀请了更多的人员参与共建。为了适应发展，团队拆分为了平台和业务两个分支。平台的同学继续维护目前的PAP，同时提高用户体验；而业务的同学则分拆到各个业务线。其目的一方面是帮助各业务线建立一套适合自己产品线的性能测试的基线、标准和方法，同时建立回归体系，保障线上产品的稳定；另一方面帮助各业务线测试同学的成长，让性能测试的范围覆盖面更广，使得面向人人性能测试的终极目标更进一步。
这其间，我们团队获得了技术质量部共建优秀团队奖，同时产品共建支持了包括QR、TMD、DUBBO、QTEST、DDOS等更多协议和工具的性能测试工作；也支持了作为JAE的对外核心性能测试平台的工作，同时我们通过双十一和聚石塔的合作，逐渐开始向外部客户发展。从刚开始的ISV到目前的阿里云所有客户，以及面向更多的客户，基于PAP开发了支持ISV双十一等活动的JST_PTS和支持阿里云客户的ALIYUN_PTS，同时也围绕着阿里云客户的需求，融入DTS和管理平台，引入计费模式，最终使得PTS对外正式发布收费，向云测之路又迈出了坚实的一步。
性能测试评估和流程
在支持外部客户性能测试的过程中，我们发现，大量的用户认为性能测试只是传统的压测，使用压测工具，配置一个url或者录制一个url就完成了，然后直接开始压测。
其实工具只是一个辅助手段，一个工具有大量的配置规则，一个url也有很多的内容组成，要找到一个适合自己的压测工具、压测方法和压测手段，同时也要了解压哪个url，以及压测url的哪一部分是适合的。
例如一个页面有以下的问题：
第一次测试，网站并发数没有超过35个，大量超时。
第二次测试，网站上做了优化以后，并发用户数100以内时响应5s，200以内时90%响应在15s以上，随着并发用户数的增加，页面响应最高可到20多秒。
注：测试工具Loadrunner
我们该如何评估和分析呢？
首先我们要了解这个URL的访问过程如图1所示，分别从访问路径和URL包含内容来分析。
图1URL的访问过程
这里，URL经过浏览器，通过网络进入服务器；再通过网络，进入数据库存储，最后返回给用户。
所以性能的评估也要从这几个方面去分析，我们压测的是不是这几个路径，需要压测什么，需要怎么压。
根据以上的路径分析出：
●2.1前端性能测试
反观淘宝的静态资源都是存放在CDN上，而且有独立域名，这样用户不会和服务器响应共用一个网络，就不存在网卡的瓶颈。
淘宝网的性能测试主要针对5%-10%的html服务器资源进行压测的，基于以下两个因素：
图3常见的前端测试工具
而PAP也有基于WebPagetest的前端性能测试工具，具体的使用方法这里就不再介绍。经过测试后，可以优化的点包括：
优化效果对比如图4所示。
图4优化效果对比
Loadrunner里面，去除静态资源的选项如表2所示。
表2Loadrunner里去除静态资源的选项
●2.2服务器端性能测试
了解了前端性能测试的原因和方法，我们来看服务器端性能测试方法。
首先，需要了解一下性能测试的指标，如表3所示。
表3性能测试指标
图5load
图6性能测试的指标GC
●2.3PV与TPS的分析
对于一个性能测试，最关键的TPS是怎么换算的。例如用户的预估或者实际的网站访问（PV/天）符合一个正态分布，如图7所示，从0点到24点，那么用户高峰访问的每秒PV，就是我们所要计算的TPS，也就是我们压测的性能目标。如图8所示。
图7PV曲线
图8PV访问图拆分成不同的矩形换算TPS
所以，平均一天的PV就是PV×80%/（7/16）=X，这个X是平均值，由此计算出它和高峰的系数，PV（F）/X=Y，Y就是系数。那么，用户只要知道他的一天PV是多少，根据这个公式就可以计算出高峰PV，也就是所说的TPS，然后把它作为性能测试的目标来压测。
●2.4测试方法诠释
图9系统处理能力的变化趋势
图9显示了性能测试过程中，随着压力的增加，系统处理能力的变化趋势：
a点：性能期望值
b点：高于期望，系统安全
c点：高于期望，拐点
d点：超过负载，系统崩溃
表44种类型的稳定性测试
表5通过标准
基于云产品的门户网站性能优化案例
●3.1背景
该门户网站的服务器存放在华通和阿里云的平台上，所以对华通和阿里共建的云平台安全及应急措施要求也非常高，需要团队给予全力的保障和配合。
先介绍一下PTS，性能测试服务（PerformanceTestService，简称PTS）是集测试机管理、测试脚本管理、测试场景管理、测试任务管理、测试结果管理为一体的性能云测试平台，可以帮助您全方位的评估云上系统性能。如表6所示。
表6PTS的产品优势
本次优化主要是使用了该测试平台服务对客户搭建在ECS上的服务器进行多种类型（性能测试、负载测试、压力测试、稳定性测试、混合场景测试、异常测试等）的性能压测、调试和分析，最终达到满足期望预估的性能目标值，且上线后在高峰期也满足了实际的性能和稳定要求。
●3.2评估
本次性能测试过程的参与者包括了阿里云应急保障小组等多部门人员，网站为外部供应商开发，阿里云提供云主机和技术支持。
●3.3分析
结合Loadrunner的使用经验，团队的第一感觉就是用户测试方法可能有误，一个页面加载对于阿里的应用来说，都是1秒以下的，也就是毫秒级别的，不会出现几秒的现象。而用户测试结果都以秒来衡量，所以测试页面肯定是带了静态资源一起压测的。
这种场景适合如JS、css、image等静态资源和后端代码放置在同一台服务器上的情况。
图11组成网站响应的4部分
●3.4测试和优化
先不讨论原来的测试方法是否准确，我们首先以测试和优化为目的，对该门户网站进行测试和分析，内容包括以下方面。
3.4.1页面前端分析和优化
对页面的优化从前端开始。首先通过PTS的前端测试工具（未开放），再结合Yslow（yahoo前端测试工具）、Pagespeed等扫描，发现以下问题并进行优化。
第一阶段性成果：在进行了第一轮的前端优化后，性能提高25%，首页响应从1.5秒提高到1.1秒，并且前端优化持续进行。如表8。
表8前端优化的结果
前端页面最终结果：
3.4.2服务器端优化
PTS脚本编写和场景构造
并行：各个页面使用不同的任务，采用并行的混合场景执行，同时设置一定的比例（并发用户数），保证服务器承受的压力与实际用户访问相似。
场景并发用户数：经常会遇到“设置多大并发用户数合适？”的问题，我们有一个公式。
注意：使用外网地址压测可能会造成瞬时流量较大，产生流量计费，建议使用内网地址压测，避免损失。
第一阶段
在按照客户提供的4个URL请求构造场景压测以后，根据实际情况和客户要求，使用PTS，构造相应的场景和脚本，模拟用户实际访问情况，并且脚本中加上了img、js、css等各一个的最大静态资源。
条件：5台ECS机器，300并发用户数，一个后台页面加3个静态页面（共150K）；
结果：静态4000TPS，动态1500TPS，服务器资源：CPU98%。如表9所示。
表9使用PTS脚本编写和场景构造的条件和结果
分析和优化
服务器资源消耗较高，超过75%，存在瓶颈，分析平台显示如图12所示。
图12分析平台显示结果
分析：主要原因是apache到tomcat的连接等待导致，现象是100个并发压测，就有100个tomcat的java线程，而且全部是runnable的状态，轮询耗时较多。
解决方法：修改了Apache和tomcat的连接协议，以nio协议取代ssl协议。Tomcat连接数据库池由30初始调整为300，减少开销
性能对比：
思考和风险
Iframe嵌套页面的方式优点是静态资源调用方便、页面和程序可以分离。但是它的缺点也显而易见，包括样式、脚本额外注入，增加请求等等；还有搜索引擎搜索不到内容；iframe创建比其他元素慢1~2个数量级；资源重复加载；iframe会阻塞页面加载，阻塞onload事件；占用主页连接池；html5不再支持。所以建议尽量不要使用或者少使用。
当用户的图片、javascript、CSS等静态资源和后端代码在同一台服务器上时，需要模拟用户的实际访问请求，压测脚本涵盖所有链接和资源。那么使用脚本录制功能就可以采集更全更完整的脚本。
第二阶段
找到几个页面的所有动态资源后，整合成为一个事务，串行访问，同时并发压测，从而对纯服务器端进行压测。由于动态页面依赖RDS数据库，所以性能相对较差，测试结果如表10所示。
表10测试结果
图14第二阶段的TPS
RDS优化内容包括：优化点主要是调整慢sql的索引，部分sql需要调整表结构和sql写法，需要应用配合才能完成优化。优化前QPS在1000左右，优化后QPS到达6000，如图15所示。
图15优化后的QPS到达6000
优化后的性能数据如表11所示。
表11优化后的性能数据
总的TPS可以达到2000，有个失败的页面存在问题，忽略。
第三阶段
测试结果如表12所示。
可以看到，所有的事务RT加起来小于5秒的情况下，并发用户数可以达到3000，满足测试要求。如图18和图19所示。
图18第三阶段的TPS
优化前后的对比如表13所示。
表13优化前后的三项对比
第四阶段
测试结果如表14所示。
表14其他非主流站应用的性能及静态页面5个页面的测试成果
备注：
风险和问题：
①测试发现流量存在非常明显的波动，不经过某模块就无此问题，发现有大量的reset连接，会诊后得出端口复用导致的问题以及FULLNAT模式和LVS存在兼容性问题。
由于存在兼容性问题，影响到网站的稳定性和性能，暂时不加载该模块，待问题解决后再加。先使用另外一个模块代替。
不通过模块的测试结果，如图20所示。
图20不通过模块的测试结果
通过模块后测试结果，如图21所示。
图21通过模块后的测试结果
②凌晨2点，针对单点用户登入进行了压测，发现100并发，该业务接口已宕机。分析结果。
③Web服务器数据同步，发现服务器IO和CPU压力过大。
④由于目前单点用户登入入口存在架构单点宕机风险，进行登入和未登入风险验证，确认，如用户已登入后，登入业务系统出现宕机，进行简单的页面点击切换，不受影响。
⑤内存优化
图22内存优化
3.4.3架构优化
最终优化后的网站页面性能满足测试要求，优化前后的对比如表15、表16所示。
门户首页:
表15架构优化前后的对比
备注：服务器的CPU达到100%其实是一个好现象，说明我们的逻辑全部走到了资源消耗上，而不是由外部其他逻辑限制或blocked，这种现象带来的好处就是，可以集中精力从减少代码的资源消耗上解决问题，带来性能的改善；
其次，实在无法优化也可以增加机器台数，通过横向扩展让性能成倍的提高，这也是用成本换性能的方法。当然，前提是架构上支持负载均衡的分布式架构。