全链路压测最佳实践--支持10万在线用户的翼赛进行全链路压测

1、项目背景

翼赛是翼课网的业务线之一，其主要功能是在学校/区等大范围竞赛中，提供给学生的一个线上作答竞赛平台。竞赛管理人员在后台发布竞赛后，学生登录翼赛平台，进入对应的竞赛可进行考试-提交等流程。为保障线上大流量用户场景中，学生答题流程、使用体验正常，我们需要提前测试翼赛线上环境能否支撑应用场景下的大流量并发，以便提前预知&解决大流量并发引发的问题。根据线上用户使用数据，我们将并发数初步确定为10w。

2、压测目标

验证线上翼赛服务系统能否承担10w流量的并发，发现风险点。

3、压测环境

• 压测环境主要包含两部分：压测系统和被压测系统。
• 压测系统：压测系统为翼课网自主开发的一个流量控制平台-APCT。
• 被压测系统：RD在阿里云服务器上搭建的与线上测试环境一致的系统，共20台服务器，用于接收和处理压测产生的流量。

4、压测系统-APCT1.1

4.1、压测范围

翼赛涉及到竞赛管理人员在后台发布竞赛、学生在前台作答共两条主业务线。由于只有特殊的账号才能在后台发布竞赛，所以后台发布竞赛的并发不高，不纳入压测范围。翼赛作答的前台包含了PC前台和翼赛app。通过在诸葛io上获取的数据（如下图），可以看到在近一年中使用翼赛app的用户量占总用户量的94.2%，由此我们在PC和app中确定了被压测软件为app，在翼赛app中产生大流量并发的主流程为：登录-作答-提交，所以最终将本次的压测范围确定为：翼赛app的登录-作答-提交业务。

使用翼赛平台占比.png

4.2、压测场景

根据上面的数据分析，我们设计了以下核心测试链路：

测试链路图.png

4.3、apct的系统架构

系统架构更新2.png

上图为apct的系统架构。测试过程中，整个apct系统部署在腾讯云上，部署完毕后，可在前端配置测试参数（学生人数、各个链路的人数比例、流量释放规则等）然后发起测试，测试命令就被发送到中央调度引擎（图中的CCS）。CCS(CenterControllerServer)并不直接发起流量，它主要是负责与之连接的多个压测引擎的调度和管理。当它收到来自浏览器的测试命令之后，就根据其配置文件中配置的相关参数配合内部调度算法将测试命令拆分成多个对应单个引擎的测试命令，然后将拆分处理后的命令分发给本次测试需要使用的各个压测上。压测引擎收到来自CCS的测试命令后，就启动对应的压测脚本向被压测系统产生流量。在压测脚本运行的过程中，会实时收集被测系统的响应数据，上报给DRS服务，DRS将收到的数据存储到kafka集群，Spark从kafka集群中获取数据并计算，将计算结果进行一系列存储处理等，最终展示在前端。

4.4、apct功能架构

压测系统-apct是一个分布式的流量发起和监控平台，它主要具备以下功能：

功能架构图.png

4.4.1 发布竞赛

由于翼赛后台账号的特殊性（只有特定权限的账号才能发布），我们设计的竞赛发布前端页面如下。在该页面中填写发布翼赛必要的参数：竞赛后台用户登录名，竞赛后台用户登录密码，布置的学校名称，竞赛试卷id，竞赛名称，竞赛开始时间，竞赛结束时间，竞赛作答时间，竞赛学生数量，竞赛练习试卷id。点击“确认发布按钮”，参数校验通过，就可以发布一场竞赛，如以下截图。

发布翼赛页面.png

4.4.2 一键压测

发布竞赛之后，页面自动跳转到发起压测页面，上传学生账号，填写必要的参数：压测场景名称，需要模拟的学生人数，流量释放规则，各个链路场景的学生占比，点击“开始测试按钮”，参数校验通过并且已到竞赛作答时间，即可发起压测，如下图：

一键压测页面.png

4.4.3 压测数据处理

压测过程中压测引擎采集的各种统计数据将会上报到APCT相关业务，经过一系列的处理计算之后业务相关数据以折线图的形式展示在浏览器页面中，接口相关数据以散点图的形式展示，如下图：

1. 以下图形中的数据以5s为一个时间单位；
2. 登录相关曲线图中，黑色线表示当前时刻的数据（当前5s内），红色线表示从开始到当前时刻的累计数据；
3. 测试过程中设置的接口连接超时时间为10s，接口read超时时间为10；
4. 从登录成功数的曲线可以看出，学生的流量是分批释放的，在18:56左右，全部学生释放完毕，此时流量达到高峰；
5. 此处图片均为测试总数据（压测引擎上的数据+观察引擎上的数据），观察引擎上的数据见5.压测结果；
6. 关于接口返回错误的定义：当接口响应超时、接口没有响应超时但是返回数据错误，均记为接口错误。
   
   登录成功/失败率.png

登录成功/失败数.png

接口并发量.png

接口错误率.png

接口响应时间.png

4.5 压测策略

4.5.1 引擎配置

为实现10w并发，我们共使用了2998台压测引擎，每个引擎上33-34个并发线程，2998*34≈10w。

4.5.2 逐步增压

根据线上数据统计，高峰时期的流量通常是40%~60%的学生在竞赛开始后30分钟内进入作答页面。在压测过程中，为了模拟的更加真实，我们采用了逐步增压的流量释放规则，即每10s释放500个用户，在34分钟内将10w学生释放完毕。通过4.4.3中的登录成功数图也可以看出，前期流量是逐步释放的。

4.5.3 观察对比

由于测试过程中，每个压测引擎都会发起大量的流量到被压测系统，当在前端观察到有数据异常时（比如某个/某些节点出现大量失败），我们无法判断此时到底是客户端本身导致的错误，还是被测服务的错误，所以我们为每个测试场景都设置了观察引擎，以便观察验证我们的服务是否正常：

登录观察引擎：与登录压测引擎业务一致，只是观察引擎上采用单线程、低并发、无sleep、持续运行。单线程、低并发是为了排除客户端本身的影响，无sleep、持续运行是为了尽可能多的采集到被测系统的响应数据。由于观察引擎的并发很低，那么只要它可以正常响应，我们就认为被测系统是正常的。

作答观察引擎：与作答压测引擎略有区别，压测引擎上完成的业务是“登录-作答（全部小题）-提交”，观察引擎上完成的业务是“业务-作答（仅作答一道小题）-提交”。观察引擎上采用单线程、低并发、无sleep、持续运行。单线程、低并发是为了排除客户端本身的影响，仅作答一道小题即提交、无sleep、持续运行都是为了尽可能多的采集到被测系统的响应数据。

5、压测结果

5.1 测试总数据

1. 从登录相关曲线图中可以看出，10w并发流量上涨的过程中，会有部分学生登录失败，再结合接口响应时间和接口错误率散点图，可以看出导致这部分学生登录失败的接口大部分是“/user/fastlogin”接口。
2. 从接口错误率散点图中可以看出，在流量上涨的过程中，“/exam/loadexamtest”接口的错误率由20%逐渐增长到75%左右。但是从接口响应时间图中看到，该接口并没有出现大量响应超时的现象，这是因为“/exam/loadexamtest”这个接口在高并发情况下返回了“服务器并发异常”的信息，期望返回正常的竞赛题目信息。当返回“服务器异常”的信息时，将该接口记为错误+1。
3. 从接口错误率散点图中可以看出，在后期提交正常竞赛时，“/exam/saveracedraft”和“/exam/submitrace”接口错误率不断上涨到30%左右，而从接口并发图中看出，这两个接口在错误率上涨时，刚好处于并发量上涨阶段。

登录成功/失败率.png

登录成功/失败数.png

接口并发量.png

接口错误率.png

接口响应时间.png

5.2 观察引擎数据

1. 测试过程中，观察节点一直保持：登录-作答-提交的无sleep循环，每个循环大概平均耗时4s（不考虑接口超时等特殊情况），观察节点最先启动整个测试过程中一直运行，但是由于流量释放规则是每10s释放500个学生，不能保证每个时刻的异常都能被观察节点捕捉到。
2. 尽管观察引擎中没有catch到所有的接口错误情况，但是从三个接口相关图中仍能得出与测试总数据中的2和3相同的结论，此处不再赘述。
3. 关于接口返回错误的定义：当接口响应超时、接口没有响应超时但是返回错误数据均记为接口错误。

登录成功/失败数.png

接口并发量.png

接口错误率.png

接口响应时间.png

5.3 结论

1. 在流量上涨过程中，“/exam/loadexamtest”接口的错误率不断上涨，“/exam/loadexamtest”这个接口在高并发情况下返回了“服务器并发异常”的信息。
2. 在后期提交整场竞赛时，“/exam/saveracedraft”和“/exam/submitrace”接口错误率不断上涨。
3. 综上，我们认为目前线上的翼赛环境在10w并发的情况下存在风险，需要针对上述两条结论进行优化调整。

6、投入时间&资源

6.1 时间节点

项目时间节点.png

6.2 引擎资源

引擎资源.png

来源：翼课网技术团队