分享一个案例：

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

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

具体该如何实施压测呢，这里划分了几个环节：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个左右事务，该数值基本能保障并发用户注册的需求。

涉及到到压测工具为自压测宝