【性能测试】系统性能容量

接到业务方性能测试的需求，需要评估当前系统可以支撑的用户量，在这个性能测试过程中踩了很多坑

阶段一：请求比压测

由于无法在线上进行测试，按照之前的做法，评估线上请求量top20的接口，按照tps的比例在压测环境进行压测
受制于环境和资源，压测环境比如mysql、redis、nginx等的资源无法和线上一致，压测一轮后发现tps远低于理论支撑值，得出的性能数据完全没有参考意义

阶段二：单接口单实例压测

在这个基础上又做了一个不是那么明智的决定，通过单个接口，对于单个实例进行压测来评估系统的容量，而且还验证1个实例、2个实例、4个实例的tps是否倍增，后面当用户量猛增后发现本次测试得出的性能数据即使乘了系数依然打脸打的够疼

阶段三：全链路压测

线上环境比如db隔离影子库等环境都没有具备，无法直接在线上进行测试，而且这些环境的准备时间上来不及，只能在阿里云上搭建一套和线上环境一模一样的环境进行全链路压测
步骤如下：
一、业务架构和调用关系梳理

业务梳理

1. 梳理业务调用链关系
2. 依赖的中间件关联（zk、mq、db、ES、redis、nginx等）
3. 依赖第三方服务（特别是收费服务需要切断）
4. 画出性能测试拓扑图

二、核心场景及操作

1. 由于对于压测业务了解不足，需要和功能测试小伙伴一起了解业务场景，梳理出核心场景（本次梳理了10个场景）和操作后，与产品经理一起确认拍板
2. 这个阶段需要确认不同场景的TPS占比，但是业务埋点中并不能获取该数据，想了一个方式，抓取场景的node接口请求，找出仅在这个场景中请求的接口做为这个场景请求的tps

三、抓取各个场景所有node层接口请求

在这个过程中发现的问题

1. 在一个场景中单个用户的操作对于单个接口进行重复请求
2. 没必要的请求比如在不同的业务逻辑情况下前端均对后台发起请求

四、编写脚本

1. 编写脚本其实并不难，主要是效率的问题，后续需要考虑如何拉取线上流量进行全链路压测，这样可以大大提高当前的效率
2. 需要将脚本中的变量进行参数化且单数据单线程调通当前脚本

五、构造场景

需要结合场景，通过脚本模拟出对应的并发，比如QPS配比，比如不同数据请求（如班级人数等）
在场景模拟时发现一个问题：
有一个这样场景，比如一个班级1个教师50名学生，需要同时并发教师发送一个答题板，50个学生同时对于这个答题板发送答案，而且同时并发这样的班级100个，固定答题板id在csv配置文件？问题在于答题板学生仅能回答一次
尝试如下方案：

1. 使用setup线程组的方式，但是setup线程组仅执行一次而且执行结束后再执行其他线程组
2. 线程组中按照顺序，教师发送答题板，学生ABC…依次针对该答题板进行答题，这样在jmeter中学生是依次对答题板进行答题，并不是真正对并发
3. 通过计数器+if逻辑判断的方式，当count%50 == 0 时进行教师发送答题板操作，可以实现
4. 通过jmeter线程id+if逻辑判断的方式，当线程id == 0时进行教师发送答题板操作，可以实现 3和4可以实现场景需求，但是需要注意的是，需要在if逻辑判断后增加集合点，这样所有的请求均等待if判断逻辑执行结束后再执行后续的逻辑

六、数据准备

数据准备主要是三个问题：

1. 如何构造需要的数据
   测试数据由开发创建并提供对应的csv列表
2. 如何将数据拆解成对应数量的文件
   目前使用事先写好和定制编写脚本可以快速事先
3. 如何将相同名称不同内容的文件放到不同的肉鸡
   蓝鲸智云处理文件下发

七、压测调优

调优过程中发现的部分性能问题如下：

1. SLB跑满导致QPS上不去
2. coredns实例数太少，dns解析失败
3. node层长链接导致响应时长过长
4. nginx实例不足，接口请求出现少量502 Bad Gateway
5. 每次获取信息都触发获取统计计数，并发请求时存在大量db更新，容易形成锁，需要修改成缓存异步方案 等等问题