高速增长的互联网业务要求产品开发、迭代和交付周期越来越短，而IT基础设施的广泛云化和第三方API接口的大量使用，使传统的基于内部环境搭建的压力测试方法和测试工具越来越难以满足应用功能可用和容量规划预估的需求。

　　企业该如何为频繁的市场活动和产品快速迭代进行有效而准确的压力测试呢？希望通过云端压力测试专家，云智慧压测宝产品总监陆兴海分享的两个客户案例，为企业的云端压力测试和业务容量规划带来一些有价值的参考。

　　压测宝云压测客户案例1：压测宝如何做业务容量的测试与规划？

　　云智慧有个做旅游和摄影服务平台的客户要举办一次活动，为本次活动制作了专门的活动页面，在活动页面用户可以报名。那么在短时间内系统到底能撑得住多大的用户并发？

　　这是活动运营和技术部门必须提前考虑的问题，因为在去年举办类似活动时就出现了用户大量涌入导致服务不可用的状况，所以首先要帮助用户整理容量测试和规划的工作思路。

　　具体该如何实施压测呢，这里划分了几个环节：

　　[1]场景确定与压测脚本准备

　　用户在注册时需要提交用户的姓名、手机号和手机验证码，之后提交申请即可，所以实际上用户申请注册只调用了一个API接口来完成，这是一个比较简单的场景。

　　1、因为涉及到手机验证场景，在不提供对应API的情况下，建议用户使用万能的验证码或者暂时取消验证码;

　　2、是否允许多个手机号同时注册，如果允许我们可用使用固定参数传递，如果不允许，我们可准备对应手机号的测试数据来应对;

　　3、短时间内发起大量并发，用户本身是否有安全挡板，如果有，需要把施压节点的IP加入白名单;

　　[2]施压模式

　　既然是容量探测，所以整体的施压过程是一个梯度渐进的过程，一般不会上来就是一条直线。这是一直和用户强调的问题，压测的目的绝对不是把系统压垮，压测的目的是通过不断增加的并发来客观评估系统在不同的压力条件下的性能状况;基于此我们定制了施压的梯度压力模式，如图所示：

　　[3]压测点分布

　　传统压力测试工具主要在内网产生压力，压力的规模受限于物理机器及License数量，造成准备周期长及成本高等问题。而云压测提供可靠的分布式压测服务器(压测点)，充分利用云端的计算资源，从而突破了这个限制。

　　目前云智慧的压测点来自云服务的云主机(AWS、Ucloud和阿里云等)以及云智慧部署在全国各大IDC核心机房的服务器，目前主要提供的区域如下图所示：

　　[4]压测时间设定

　　根据系统访问情况，一般会建议用户在凌晨进行压测，此时能够保证对用户的影响最小，也能保证正常用户访问对压测结果的干扰最小。但这个压测时间设定不是绝对的，需要与具体用户的业务场景结合判断。

　　[5]压测数据分析

　　在基本的参数确定之后，就可用根据预定的时间来执行压测任务了，云压测能够进行秒级的数据采集和实时统计分析，能够随时调整压力。随着压力的逐步上升，能够动态呈现系统的性能数据。在逐步加压的过程中，如果性能急剧下降或大量出错，就没有必要继续执行压测任务，此时可以终止任务，也可以下调压力，确保对整个压测过程的把控。

　　针对这个用户，按照上述步骤实施压力测试之后，通过相关测试结果的数据分析和评估，得到了压测结论如下：

　　被压测的注册接口在360并发用户以下时表现相对良好，在并发用户达到360至500时性能欠佳，说的更直接一点就是：该系统能够支撑360的并发，具体论证如下：

　　1、并发达到360之后失败明显增多并且持续到任务结束;

　　2、并发达到420之后，响应时间超出3000ms标准值且持续到最后;

　　3、每秒钟事务数(TPS)稳定在130左右，表现比较良好;

　　本次压测的概要数据如下图所示：

　　压力测试综合报表如下图所示，当并发用户数达到360时，系统开始出现了大面积失败(280时出现了1次错误)，并且失败问题持续到压测结束都没有改善，不过整个测试过程中并没有出现断言不匹配的情况，即正确性保持良好。

　　事务响应时间趋势：随着应用访问用户量增加，在并发用户达到420的时候，系统事务处理的时间也显著上升(大于参考标准3000ms)，且响应时间在以后一直没有下降。

　　事务处理性能趋势：当压力稳步上升后，应用事务处理能力保持平稳，基本维持在每秒钟处理130个左右事务，该数值基本能保障并发用户注册的需求。

　　压测宝云压测客户案例2：基于压测的后端性能问题分析与定位

　　下面介绍另外一个用户的真实需求场景，这里着重分析用户在压测时遇到的性能问题，主要从失败和响应时间缓慢两个角度，首先是失败情况，如下图所示，失败的类型及其占比。

　　在整个测试过程系统从5:05分开始出现逐渐增加的不同类型服务器处理错误，导致事务处理失败，具体错误信息如下：

　　502：错误网关(从5:43～5:46共出现112次502错误);

　　600：connection连接异常，从5:05～5:50共出现264次600错误);

　　601：Socket异常(5:31和5:47出现2次601错误);

　　603：拒接服务错误(从5:21至5:49共出现48次603错误);

　　其实是响应时间分析，如下图所示某个事务及其对应的请求情况。

　　从上图可以看出“好友动态”的平均事务请求响应时间为10,862ms，是其他应用请求的平均响应时间的7倍(其他请求平均响应时间为1,400ms)。

　　上图为从压测宝系统获取的一次好友动态事务请求响应日志，可以看出响应时间为12232ms，其中连接时间为3136ms，请求返回的内容非常大(51764Bytes)。和其他应用相比好友动态应用耗时非常长，用户体验很差。

　　在本次压测的全程，基于云智慧的应用性能管理产品透视宝来进一步分析后端性能情况，通过后端应用请求分析可以查看一段时间内Web应用处理事务请求的响应时间、请求数及详细的请求信息及变化趋势。在并发用户超过200时响应时间明显变慢，但整体系统响应时间表现正常(处理时间小于500ms占比 74.13%);

　　接着我们利用透视宝的代码级堆栈定位分析功能来进一步分析数据库SQL情况，如下图所示。

　　通过后端关键事务快照可以看出单次请求处理的数据库连接耗时1400.92ms，占比95.23%(总响应时间1471.02ms)，是主要的数据库耗时来源;

　　可以看出数据库查询操作耗时占比3.71%，是数据库第二耗时来源;而且多个数据库查询SQL语句大部分查询条件相同，在高并发量用户查询时有较大的性能优化空间。

　　基于以上的分析，建议用户从如下方面进行优化：

　　1)如果应用处理入口有前置负载均衡服务器，建议对负载均衡服务器相关参数进行优化，提升用户请求入口处理能力;同时建议对负载均衡服务器进行性能监控，及时发现系统瓶颈;

　　2)事务请求处理过程中数据库连接耗时较长，建议采用数据库连接池组件进行性能优化;

　　3)建议在系统架构中增加数据库缓存，同时对类似的SQL操作进行处理优化，以减少后端数据库的连接次数，提高数据库查询效率和性能;

　　基于请求的深入分析，在压测宝中提供问题请求的详细快照，包括请求的响应时间分解、请求头和返回结果，如下图所示。

　　另外如上面所示，在压测宝的单次请求追踪部分集成了性能管理产品透视宝，能够通过单次请求直接查看后端的代码问题，如下图所示：

　　通过对失败、缓慢与错误的事务与请求进行细化分析，包括对错误类型分析、请求快照查看以及后端深入定位。

　　以上是两个真实应用场景的云端压力测试分析案例，通过性能压力测试(压测宝)我们可以清楚的知晓业务容量规划，并发现系统中影响业务的性能问题(请求缓慢、失败)。通过与应用性能管理(透视宝)集成来定位和诊断根源问题，深入分析后端的性能瓶颈来提升业务质量，从而实现应用的快速优化和上线。