悬镜安全扫描导致4核cpu负载使用率400%

【背景】

1、某KA项目通过压测执行结果qps24较低，曲线有毛刺，95ht延迟5秒左右较慢，同时看到后端服务4核cpu已打满400%，反馈给研发同学排查问题

接口：/pwp/rest/portalgxhaction/getAllAppData 12获取应用列表

吞吐量(req/s)：24.34

报错率：0%

95%分位的平均响应时间（ms）：5330

并发量：100

持续时间：300s

数据分析：qps24较低，曲线有毛刺，4核cpu已打满400%

测试时间：2021-11-24 21:20:18 到2021-11-24 21:25:45

【排障过程】

17:00 研发一开始以为是sql慢查询导致cpu资源占用打满，TDsql全局搜索慢qls也没监测到

17:09 陆斌 ，讨论用火焰图打印排查

17:14 陆斌 ，看下web服务器，cpu压测力也就20%左右

17:15 赵步旺，那个cpu20%左右是那个数组机的，不是我们这个pod的，所以那个没有关联，应该看下我们pod下面的cpu

17:17 徐攀棒，那个cpu为什么那么卡？cpu资源负载达到400%左右

17:18 仇洋菁内存消耗6G多，内存还没满

17:21 赵步旺把火焰图打印出

17:35 赵步旺同步业务类的存在应用服务里面

17:37 压测打印耗时

17:38 压测看打印结果

17:40 压测耗时正常，耗时都没有超过1s

17:41 陈虎兵，这个是框架的安全防护，拦截较多

17:42 当时这块没有做过性能压测分析

17:44 发现安全模块两个过滤器get filter，一个是下面的那个post filter，等于做了两次安全监测。占用cpu使用率70%左右

17:45 陈虎兵明确了现在的性能个瓶颈就是在我们的这个web节点的cpu上面，这个已经明确

17:46 单容器单里面的四核cpu已经全部用完

17:47 调日程，把日程的过滤器调整一下配置

17:49 查看两个过滤器代码

17:51 authorized方法代码更改重写一下这个方法，认证通过返回值为空就可以

18:28 厂商悬镜安全整改完成，需要项目组申请。申请时长6小时

【复测结果】

整改完成后的压测结果

接口：/pwp/rest/portalgxhaction/getAllAppData 获取应用列表

吞吐量(req/s)：172

报错率：0%

95%分位的平均响应时间（ms）：1690

并发量：150

持续时间：300s

数据分析：

测试时间：2021-11-24 23:47:18 到2021-11-24 23:52:45