1v1 教学平台线上压测踩坑经验分享

一、线上压测背景

1、公司业务组织大联考活动 实际报名数量翻倍增长，大大超过原计划课耗，如临考试日期，会存在集中登录去考试的流程，此时并发量较大。

2、连续两周出现后端服务不稳定的情况，要么 CPU 被打满，要么 DB 数据库被打满。

3、由于业务发展招师课堂需支持单节课 3000 人以上的大培，之前单节课只支持 1000 人同时在线 ，但是实际上每次我们大培都在 1500 以上，每次需要开启两台电脑两节课进行培训，根据业务发展需要我们需要支持 3000 人以上的大培。

根据上面的需求背景，把压测任务拆解为了两个方面：

• 招师课堂做改造并进行压测 -- WebSocket

• 客户端首页服务压测 -- http

主要目标：发现隐患 和 容量探索

二、线上压测面临实际情况

课量暴增。。。。

暑假高峰期将近。。。。。

特定时间的课量分布。。。。

涉及到的链路多且长等等。。。。。

因此我们不得不进行线上压测，监控链路真实瓶颈

本文不对 JMeter 压测脚本做过多说明，主要是希望我们的前车之鉴（坑）能为各部门铺垫好，精准目标方向，加大产出效率

三、线上压测前的准备

Q1：关于测试脚本准备，为什么只选择首页接口？

A1：4.10  9:00-9:07 后端服务报错，批量获取课程信息接口超时，导致多个服务异常，无法备课

原因：后端的备课服务设置的连接池不够用，导致首页代办请求量上来了，需要查询备课信息。9 点的课量上万节，比其他点多了 30%-50% ，目前先扩容来暂缓

Q2：关于缓存， 压测缓存怎么办？

Q3：测试账号问题，这么多并发需要准备这么多账号吗？

Q4：Token 问题，如何绕过 Token 校验？

Q5：监控工具，用什么工具监控链路和服务？

Q6：WebSocket 压测脚本，如何配置才能达到一个真实课堂情况？

A6：此次压测用的是 JMeter，脚本参数如下图

四、本轮线上压测成果

WebSocket 招师课堂压测：

方案A：单台机器升级配置 8C16G 升级到 16C32G 之后流量打到一台机器上是否支持 3000 人上课？

结论：压测后发现存在内存溢出，方案A 失败告终，详细如下图

方案B：将流量负载均衡到一个集群的所有机器上，能否支持 3000 人上课？

结论：经过三轮压测，可以得出多台机器进行负载均衡可以满足 3000 人以上的大培教室，方案B  PASS，具体详情如下

第一轮压测发现持续一段压测时间后老年代 GC 加大且无释放趋势

第二轮压测发现了消息才是罪魁祸首的 GC

结果很明显，消息发送越频繁，内存消耗的越快

分析过程本文不做详解，感兴趣的小伙伴可追溯到先前文章 ---- Netty广播场景压测内存泄漏破案全流程

大概是 GC 的内存走势因为老年代突然加大，内存中的 QPS 达到峰值无法销毁导致年轻代来不及回收，本该需要回收的对象，在 CPU 允许的情况下并没有 GC 掉

解决方案：

2、减轻负载压力，增加更多的负载机提升各自消息的读取速度

成果：经多次测试，无论消息多么频繁 都不会造成内存暴涨，水位的控制达到了明显作用

第三轮调优后的压测结果：

招师课堂单机 4C8G 配置保底至少可支持 2000 人容量，并且 3-5 小时内的监控指标都维持平稳，此次验证总算成功结尾

PC客户端压测：

1、先尝试探索压测了两轮，发现了学生App 和 老师Pc 两个服务的 CPU 瓶颈，学生App 熔断缺陷，另外容量极限还需要持续压测

2、首页核心服务线上压测，结论如下

第三轮 ---- PC老师端：

第四轮 ---- 学生APP 和 学生PC 结论：

压测后发现学生移动端网 10338 和 11415 压测时 1% 左右的报错是因为线程池设置不合理，经过优化之后第二天再次进行了 1000 的并发压测没有再报错

3、最终四轮优化下来的成果：核心服务学生端老师端在最高峰流量成倍的情况下也能保持稳定

五、踩坑经验总结

1、WAF 防火墙机制

发生场景：刚开始跑低并发进行预热都没有问题，直到并发量的时候开始报错，脚本执行过程中全部返回报错

解决方案：

1. 找运维加域名白名单 

2. 提供压测机的出口 IP 进行 WAF 解封

2、网络带宽限制

发生场景：压测过程本地 ping 不通，带宽被打满

解决方案：

1. 多台负载机不同网络环境
2. 提升网络传输速度，最好是有线网络和台式机器（一般的笔记本网卡都有限制速度，且不稳定）

3、内网跳板机被限流

发生场景：3000 并发与 1500 并发的 CPM 量竟然一样，最后查看某台机器的流量发现无变化，可得知被限流

解决方案：需要放开 VPC 出口 IP 的流量，防止被限流

4、存在熔断机制

发生场景：压测过程报错太多导致接口触发 熔断机制，脚本直接返回报错

解决方案：

1. 扩大线程池配置

2. 上下游服务机器扩容

5、一个集群里相同配置机器性能不一致

现象：多次测试结果如下图，标记的阿里云机器远不如其他机器

解决方案：需检查宿主机 是否存在超卖现象

6、socket 持续长连接压测，可能会被上报的日志打满导致 crash

现象：招师课堂压测一段时间后，发现上报埋点的接口报错,客户端 crash 白屏

解决方案：精简埋点上报内容，做到稳定持续输出

7、socket 测试环境压测招师课堂与生产环境的压测区别

现象：测试环境没有出现过客户端 crash，生产环境却不停在 crash 白屏

缘由：测试环境与生产环境的埋点方式不一样，导致测试环境无法复现，生产环境上传的埋点数据过大导致客户端崩溃

解决方案：切记一定要检查测试环境与生产环境的差异，才能模拟最真实情况

8、依赖方发布导致压测数据明显异常

现象：头一晚压测 10418 服务都正常， 但是第二天同样环境和压力上去，10418 挂了，追查原因是 11228 服务 CPU 瞬间 打到 80% 以上并且看到流量只打到课程的 两台服务器上了

解决方案：压测之前需与依赖方沟通好，避免压测过程中依赖方发布拉入拉出集群机器 发生冲突。

9、下游服务的慢sql 导致压力上不去

现象：慢sql 直接导致数据库 CPU 被打满

解决方案：

1. 后端开发过程中针对测试覆盖不到的地方要加缓存，要有设计。
2. 对如何写出高性能的 sql 要有基本的素养和培训，这次的 sql 里面 居然包含两个 select* 以及 union 查询，即使数据量很小，这个 sql 本身 就超级耗性能。
3. 后端接口上线第二天需要有人监控 DBA 的 慢sql 平台。

本文主要给大家讲述  耗费数个晚上踩坑历程，坑位虽多，但颇有收获。

其实整个压测过程就是一个不断优化不断改进的过程，通过长期的循序渐进的改进不断发现问题，优化系统，才能让系统的稳定性和性能都得到质的提升。

总之，生产的稳定性是服务的基石，尤其对我们性能来说稳定压倒一切！

我们的目标是：

轮询化：线上链路测试机器人，实时监控，检测生产服务；

常规化：减少人力成本投入；

日常化：尽可能白天完成压测工作，毕竟熬夜不利于身体健康；

图形化：链路压测规划图形化展示，与业务结合，一键完成数据准备工作。

By  the  way 目前正在开展流量回放平台，采集到最真实流量数据，后续会慢慢投入精力去探索发掘价值，为全链路压测贡献一份力量！

掌门 MySQL 数据库规约落地及优化实战

INFRA-JOY微服务治理验证工程实践分享

掌门持续交付流水线大规模实践