一次性能问题定位

项目场景：

对系统进行一次新增接口的性能测试

测试接口：新增接口

测试场景：登录-循环控制器（新增接口-100次）

线程数：10

---

问题描述：

测试过程中发现，新增请求响应时间为300ms左右，相对不高；tps达到30以上，相对可观

后台监控发现数据库使用率达到100%，并且负载超高；

由此产生产生了疑问，明明请求响应时间比较短，整个接口业务链路也不涉及到响应时间长的请求，数据库CPU使用率和负载都不正常，CPU主要消耗在us，为正常应用程序消耗

原因分析：

经监控工具接口响应时间进行排序，查询发现，有一个请求响应时间超过3-5s，而且压测时产生的数量较新增接口相差无几；通过查看详情拿到详细的sql语句

拿到sql语句后，经与开发讨论确定与这条语句相关的业务，为新增后，会保存对应业务类型的统计数据，在保存统计数据的时候需要进行查询；此请求为后台服务自动产生的一个异步请求，响应时间不包含在新增请求内；此sql语句在where后面的查询条件字段，并没有添加索引；

解决方案：

优化方案：由于is_delete为状态字段，包含两个状态0和1，并不适合建立索引，因此在issue_id上建立索引，索引建立之后，对接口业务进行回归；

回归发现，数据库服务器资源使用情况变得正常，从100%到小于5%；该请求响应时间从4秒左右到小于10ms；效果明显

总结：

总结：压测接口响应时间短，不代表业务没有问题，当前系统架构较复杂，后台服务之间的交互不完全暴露在前端，因此测试的时候，需要对整个业务链路进行全链路监控；方便定位到具体问题；

全链路监控工具推荐：Skywalking8+elasticsearch7

链接地址：https://blog.csdn.net/chen6722/article/details/115328744?spm=1001.2014.3001.5501