【背景】
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
