基于云的全链路性能测试理念与产品实践

2016年京东618电商节已经告一段落，从6月1日到18日的大促期间，京东累计订单量过亿，618当天（00:00-24:00）下单量同比增加超过60%。其中，移动端下单量占比达到85%，是去年同期的2.2倍。如何保障大流量下的系统高可用性，成为京东电商平台每一年一度的“高考”。

因为京东平台架构的复杂性，为了保证系统的高可用，在传统压力的基础上，京东全面采用了线上压测和全流程压测，以观察多系统在峰值流量下的相互影响，而这些测试手段均可以概括为性能测试。性能测试是经过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。经过负载测试，肯定在各类工做负载下系统的性能，发现系统负载增长时，各项性能指标的变化状况。压力测试是经过肯定一个系统的瓶颈或者不能接受的性能点，来得到系统能提供的最大服务级别的测试。
为何要进行性能测试呢？
本文开始提到了京东618的例子，设想一下，若是在618当天由于暴增的流量致使系统崩溃，京东的网站、APP没法打开，支付不能正常交易，会给京东带来多少损失？

国外调研机构针对网站性能作过调查显示：响应时间每延迟一秒，客户转化减小7%，页面访问量减小11%，客户满意度下降16%。性能除了会形成收入的损失，还会严重损害企业的品牌，而1个互联网用户会用负面口碑影响17个其余用户。
全球电商巨头亚马逊每100ms的访问延迟会形成1%的销售损失，而1秒钟的访问延迟给亚马逊带来每一年16亿美圆的巨额损失。在中国，2015年5月28日携程旅行网出现长达7个小时的服务瘫痪，官网和App均没法访问，形成的直接损失约5000万元人民币。性能测试对业务的重要性一目了然。
常见性能测试术语介绍
要作好性能测试，首先要熟知性能测试的如下概念：
VU 虚拟用户数：这个概念相信你们都不陌生，线上环境里的每个操做都是一个真实用户的操做，而在测试环境不可能找来那么多的测试用户，就要用程序模拟真实用户去跑，这就是虚拟用户~~
VUM 每分钟虚拟用户数：这是一个负载参数，通常也会用来跟计费挂钩。阿里云的PTS就是按照VUM来收费的。也有压测产品Web Load Testing是按照VUH来计费的，这里的H是小时的概念。
下面介绍一下云智慧压测宝两种曲线模式里计算VUM的不一样算法。

平行模式：如上图所示，在一段时间内虚拟用户数保持不变，VUM＝VU*M

坡度模式：顾名思义，坡度模式下虚拟用户数随着时间的变化而增长或减小。坡度模式的计算方法比较复杂，与选择曲线模式的顺序和类型，即整个压力曲线的变化方式有关，最简单的状况下VUM＝（VU*M）／2 。
TPS （Transaction Per Second）每秒钟事务数：每秒钟系统可以处理事务或交易的数量，它是衡量系统处理能力的重要指标。
QPS（Queries Per Second）每秒钟请求数：若是一个脚本共3个请求，跑完一遍算一个事务数。假如1秒钟，就跑了一遍这个脚本，那么TPS=1，QPS=3。
并发用户数：多用户在同一时刻对系统执行操做，通常指执行同一事务或操做。例如你们输入完用户名和密码后，同时点击登陆按钮，这个登陆就是一个并发操做。若是100我的同一时刻点击登陆，那么咱们认为此时并发数为100。
在实际性能测试工做中，测试人员通常比较关心的是业务并发用户数，也就是从业务的角度关注应该设置多少个并发数比较合理。以一个典型的上班签到系统为例，早上8点上班，7点半到8点的30分钟的时间里用户会登陆签到系统进行签到。公司员工为1000人，平均每一个员上登陆签到系统的时长为5分钟，用下面的公式计算：
　　　　C=1000/30*5=166.7
C表示平均并发用户数，那么对这个签到系统每分钟的平均在线用户数为166
固然，在性能测试上，任何公式都不能彻底模拟真实状况的发生，最重要的是对系统作出有效正确的分析。
吞吐量：单位时间内系统处理的客户请求数量。通常用请求数/秒或者页面数/秒来衡量。
响应时间：应用系统从客户端请求发出开始到客户端接收到最后一个字节数据所消耗的时间。

6
响应时间=N1+A1+N2+A2+N3+A3+N4
针对响应时间，业内有“2-5-8原则”的说法，就是当用户可以在2秒之内获得响应时，会感受系统的响应很快；当用户在2-5秒之间获得响应时，会感受系统的响应速度还能够；当用户在5-8秒之内获得响应时，会感受系统的响应速度很慢，可是还能够接受；而当用户在超过8秒后仍然没法获得响应时会感受系统糟透了，或者认为系统已经失去响应，而选择离开这个Web网站，或者发起第二次请求。
对于API请求，因为没有页面的渲染时间，因此响应时间会更快，才会不影响用户的体验感知。
思考时间（Think Time）：用户在进行操做时，每一个请求之间的间隔时间。一般在输入用户名、登陆密码或选择查询条件等等的操做中是须要有停顿时间去输入或选择的。因此为了更真实的接近真实场景，须要加入一些思考时间。
资源使用率：负载下的基础设施资源使用状况，一般包括CPU占用率（用户使用率（%User），系统（%System））， 内存使用率，磁盘I/O， 网络I/O（带宽的流入和流出），这些参数经过云智慧透视宝能够实时得到监控性能指标。
常见性能测试工具
目前市面是比较流行的性能测试工具主要有如下几种：

1. Load Runner：Load Runner是目前的业内老大，功能比较强大，商品版本须要购买Licence，进行性能测试时能够看到实时和已经完成的报告。不过产品配置比较复杂，新手入门须要花较长时间。

2. 阿里云的PTS（Performance Test Service）：阿里云PTS产品完成度不高，新手帮助不少打不开，验证脚本比较麻烦，在试用时测试任务创建后都失败了。

3. 云智慧压测宝：压测宝是基于SAAS的性能测试产品，全链路的压测，简单易用，上手很快。

4. Soasta的CloudTest：CloudTest功能很是强大，报告自定义面板很赞！可是国外的产品，虽然支持中文，但兼容很差。

5. Jmeter：上手很简单，大量并发时会有内存溢出问题，Jmeter的报表较少，对于要分析测试性能不足做为依据，不过做为简单的接口测试和少许并发仍是不错的。
   压测宝功能实战

传统的压力测试一般被称为温室环境的压力测试。而压测宝基于云端的全链路压力测试则是真实环境压力测试。经过下表能够对比一下传统压测和云压测的区别。

压测宝的优点有：
面向真实用户业务场景及真实地域分布的性能测试；
基于压测分析应用全链路性能瓶颈；
集成透视宝应用性能管理深刻代码级问题定位；
集成透视宝分析后端的主机性能指标；
自定义多维度数据实时分析报表
除了自身的功能优点，压测宝还能和云智慧另外两款产品——监控宝和透视宝的深度集成，达到1+1+1>3的效果：在上线以前由压测宝发起压力，透视宝定位具体的瓶颈[主机，服务，代码等] ，在上线以后与监控宝集成，利用一样的脚本进行线上业务的监控告警。
压测宝的压测步骤很是简单，能够分三步走：

1.准备测试脚本和测试数据
测试脚本支持6种http请求（post，get，delete，put，option，head），支持http和https协议。在准备脚本的时候，应该验证脚本是否正确可用的，而后建立测试任务，否则就可能白白浪费测试资源啦~~

压测宝的脚本验证很是简单，一步到位就能够看到结果，而阿里云的PTS须要3步。

若是测试任务须要使用测试数据的话，要在测试脚本中定义这些初始化变量。测试数据支持csv和zip的导入，单个文件大小在60M之内。

2.定义测试任务：
一个测试任务能够跑不一样的脚本，测试脚本能够绑定测试数据，也能够不绑定测试数据。用户可以本身设定脚本的比例。

压力曲线设置：压测宝支持多个压力曲线的设置，建议先使用坡度模式，找到性能拐点后再设置平行模式。固然若是公司的性能要求必须保证500并发，也能够直接选择500VU 平行，看系统是否支持500VU。

压测点设置：压测宝用户能够根据企业实际用户分布选择最适合本身的压测点。

3.实时数据分析
运行中的压测报告是每隔10s刷新一次，能够实时查看TPS，方便客户的开发或者运维人员第一时间发现和定位性能瓶颈。若是出现严重的错误，如整个客户系统瘫痪，能够马上终止当前测试任务，节省VUM。
概要分析：

地域分析

事务分析

已经完成的任务一样会输出详细的数据报告，用户能够根据时间，脚本，地域等对结果进行过滤。另外压测宝还会有帮助手册，帮助视频等帮助新手入门。