基于云的全链路性能测试理念与产品实践
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＝（VUM）／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/305=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（带宽的流入和流出），这些参数通过云智慧透视宝可以实时获得监控性能指标。
常见性能测试工具
目前市面是比较流行的性能测试工具主要有以下几种：
Load Runner：Load Runner是目前的业内老大，功能比较强大，商品版本需要购买Licence，进行性能测试时可以看到实时和已经完成的报告。不过产品配置比较复杂，新手入门需要花较长时间。
阿里云的PTS（Performance Test Service）：阿里云PTS产品完成度不高，新手帮助很多打不开，验证脚本比较麻烦，在试用时测试任务建立后都失败了。
云智慧压测宝：压测宝是基于SAAS的性能测试产品，全链路的压测，简单易用，上手很快。
Soasta的CloudTest：CloudTest功能非常强大，报告自定义面板很赞！但是国外的产品，虽然支持中文，但兼容不好。
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。
概要分析：
地域分析
事务分析
已经完成的任务同样会输出详细的数据报告，用户可以根据时间，脚本，地域等对结果进行过滤。另外压测宝还会有帮助手册，帮助视频等帮助新手入门。
关键字：压力测试, 测试, 性能, 用户
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
