根据用户id获取对应的组织管理范围 - qps限频断层

【问题背景】

压测执行：并发数600，脚本含有依赖包，执行持续时间300秒

压测结果：qps曲线出现严重下坠以及断层，

【排障过程】

10：50发了该问题及时升级，同时拉起排障会议解决

11：00拉相关人员上会：架构、运维、研发、涉及ISV团队协助进行性能排障会议

11:02联系运维或者有后台服务监控相关权限同学

11:05需要运维或者相关权限同学协助查看整个服务链路监控：DNS ->DDOS ->WAF ->公网CLD ->政务认证服务->数据库各个服务监控指标是否存在瓶颈

11:07 监控排查发现资源负载瓶颈不在链路上面，反馈给产研同学,主要 看带宽

11:09 王，带宽限制500兆掉200多兆，理论瓶颈出现在这里

11:10 带宽曲线图与QPS曲线图一致

11:14 切换数据库-3监控图,1/2数据库是没负载的,数据库压力都打在3号数据库

11:20 进入日志oppi接口,查看报错信息

11:24 m，数据库报错看不出来问题，组件有原因导致日报错，不影响

11:25 疑问掉坑是否导致数据库代码占满

11:26 m,数据库没看到其他详细日志，重压下，打印日志

11:27 加完日志，下午继续排障

11:30查看根据时间查询表数据是有索引

11:40 麒琳，tce的mgdb，产研这边的适配工作，tce平台没了，需要确认，目前没办法，要资源没资源，要啥没啥，等后面有资源有了在查，跟产品反馈下以后把mgdb移到tce上面去

11:42 我们这边资源有限 ,目前只能调优

11:45 确认外网 压测带宽有限制

11:50 许，升级服务，完成后再复压

14:22 产研同学给出建议做出重新打包发版再进行复测

14:30 临时突破口

复测结果与第一次压测结果季度相似，当时立马反馈给产研同学，是否存在配置host问题，因为该问题在8号解决过一次，由于配置hosts里面没有这三个域名解析

14:33 问题已定位

【起因回顾】

11月8日该接口排障已通过strace工具进行日志对账，排查发现pod没有pod没有写host

研发同学，通过strace命令跟了下服务，看了下他耗时的那段时间是在干什么，发现他在请求dns，然后比对了下异常和正常机器里面的dns，发现dns没有houst

在后面的交接中腾讯产研同学没有跟道一产研同学说明改host的问题，导致道一同学在部署的时候没注意到

【复测结果】

产研收到反馈后，重新对houst配置后重启，复测4次结果比较理想