回顾下线上全链路压测

最近做了一个每日任务的项目，上线后出现了一个SQL慢查询的问题，我就反思这么重要的活动上线我没有想过去做压测/没有提前的预警高QPS下的扩容策略

想整理下全链路压测的流程：

1. QPS的预判

当我们需要上线一个活动的时候，可以根据以下两点获取预测的QPS

历史数据：历史上这种活动的最高QPS是多少

推广情况：新上线活动的推广力度是多大

需要结合产品和运营的数据，大致估算下活动力度下的平均QPS和峰值QPS

 

2. 全链路API的梳理：

需要整理整个活动链路中使用的API，每个API的权重是多少，根据权重去计算一个api对应的QPS是多少

例如 

Overview接口 app端每隔5s请求一次，权重为50。 

queryinfo接口 是针对单个用户的，获取签到状态 权重为10

completeTask接口 在每次完成任务后回调 但是实际用户完成任务后不再调用，权重为 5

 

3. 测试环境准备：

哪个环境压测呢？

线上：如果说是国内用户的话，可以选择在深夜在线上环境压测； 但是必须要相应的开发人员陪同，万一把线上压挂了但是又无法及时恢复，会造成线上事故的；尤其是在有三方依赖的情况下；更不能把三方的系统给压挂了

Pre-Prod：在阿里是有套pre-prod的系统的，如果在pre-prod进行压测的话，需要保证机器数量/配置和线上保持一致，才能达到很好的效果

QA：在QA环境可以先准备一下压测，如果发现明显的问题，就先找开发人员修复

 

4. 测试数据的整理：

线上还是pre环境的压测，首先要尽可能的使用真实的用户数据，但是同时又不能产生脏数据

需要QA去构建影子表

 

5. 测试执行

阿里是有一套亚马逊的压测平台的，目前用起来是最好用的（不愧是大厂）

测试执行过程中，需要看一下QPS 100/QPS 200 情况下服务端的CPU情况，API响应速度

同时在执行过程中，当QPS从50陡增到100的时候，看下服务器的反应情况。

 

6. 测试结果分析：

在不同QPS下服务器的压力/接口响应时间

最重要的是在这个过程中发现了哪些问题，分析出瓶颈在哪里。

 

有点干，回头回顾下以前的数据，看看能不能提供些数据