如何作云端压力测试和业务容量的测试与规划

高速增加的互联网业务要求产品开发、迭代和交付周期愈来愈短，而IT基础设施的普遍云化和第三方API接口的大量使用，使传统的基于内部环境搭建的压力测试方法和测试工具愈来愈难以知足应用功能可用和容量规划预估的需求。
企业该如何为频繁的市场活动和产品快速迭代进行有效而准确的压力测试呢？但愿经过云端压力测试专家，云智慧压测宝产品总监陆兴海分享的两个客户案例，为企业的云端压力测试和业务容量规划带来一些有价值的参考。
压测宝云压测客户案例1：压测宝如何作业务容量的测试与规划？
云智慧有个作旅游和摄影服务平台的客户要举办一次活动，为本次活动制做了专门的活动页面，在活动页面用户能够报名。那么在短期内系统到底能撑得住多大的用户并发？

这是活动运营和技术部门必须提早考虑的问题，由于在去年举办相似活动时就出现了用户大量涌入致使服务不可用的情况，因此首先要帮助用户整理容量测试和规划的工做思路。
具体该如何实施压测呢，这里划分了几个环节：

［1］场景肯定与压测脚本准备

用户在注册时须要提交用户的姓名、手机号和手机验证码，以后提交申请便可，因此实际上用户申请注册只调用了一个API接口来完成，这是一个比较简单的场景。
一、由于涉及到手机验证场景，在不提供对应API的状况下，建议用户使用万能的验证码或者暂时取消验证码；
二、是否容许多个手机号同时注册，若是容许咱们可用使用固定参数传递，若是不容许，咱们可准备对应手机号的测试数据来应对；
三、短期内发起大量并发，用户自己是否有安全挡板，若是有，须要把施压节点的IP加入白名单；

［2］施压模式
既然是容量探测，因此总体的施压过程是一个梯度渐进的过程，通常不会上来就是一条直线。这是一直和用户强调的问题，压测的目的绝对不是把系统压垮，压测的目的是经过不断增长的并发来客观评估系统在不一样的压力条件下的性能情况；基于此咱们定制了施压的梯度压力模式，如图所示：

［3］压测点分布
传统压力测试工具主要在内网产生压力，压力的规模受限于物理机器及License数量，形成准备周期长及成本高等问题。而云压测提供可靠的分布式压测服务器（压测点），充分利用云端的计算资源，从而突破了这个限制。
目前云智慧的压测点来自云服务的云主机（AWS、Ucloud和阿里云等）以及云智慧部署在全国各大IDC核心机房的服务器，目前主要提供的区域以下图所示：

［4］压测时间设定
根据系统访问状况，通常会建议用户在凌晨进行压测，此时可以保证对用户的影响最小，也能保证正经常使用户访问对压测结果的干扰最小。但这个压测时间设定不是绝对的，须要与具体用户的业务场景结合判断。

［5］压测数据分析
在基本的参数肯定以后，就可用根据预约的时间来执行压测任务了，云压测可以进行秒级的数据采集和实时统计分析，可以随时调整压力。随着压力的逐步上升，可以动态呈现系统的性能数据。在逐步加压的过程当中，若是性能急剧降低或大量出错，就没有必要继续执行压测任务，此时能够终止任务，也能够下调压力，确保对整个压测过程的把控。
针对这个用户，按照上述步骤实施压力测试以后，经过相关测试结果的数据分析和评估，获得了压测结论以下：
被压测的注册接口在360并发用户如下时表现相对良好，在并发用户达到360至500时性能欠佳，说的更直接一点就是：该系统可以支撑360的并发，具体论证以下：
一、并发达到360以后失败明显增多而且持续到任务结束；
二、并发达到420以后，响应时间超出3000ms标准值且持续到最后；
三、每秒钟事务数（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操做进行处理优化，以减小后端数据库的链接次数，提升数据库查询效率和性能；
基于请求的深刻分析，在压测宝中提供问题请求的详细快照，包括请求的响应时间分解、请求头和返回结果，以下图所示。

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

经过对失败、缓慢与错误的事务与请求进行细化分析，包括对错误类型分析、请求快照查看以及后端深刻定位。以上是两个真实应用场景的云端压力测试分析案例，经过性能压力测试（压测宝）咱们能够清楚的知晓业务容量规划，并发现系统中影响业务的性能问题（请求缓慢、失败）。经过与应用性能管理（透视宝）集成来定位和诊断根源问题，深刻分析后端的性能瓶颈来提高业务质量，从而实现应用的快速优化和上线。