记录一次利用arthas和skywalking做接口性能优化的全过程
文章目录
- 一. 场景
- 问题
- 二. 问题分析
- 1. skywalking 进行耗时分析
- 2. arthas 进行接口内部调用路径的追踪和耗时统计
- 三. 问题解决
- 四. 问题处理效果
一. 场景
最近997模式的赶需求, 对接口性能要求放松了很多，但是有一个接口耗时非常高达到了4秒。这显然是不可以接受的，下面记录下解决的过程。
问题
图中可以看到该接口响应达到了4秒
二. 问题分析
1. skywalking 进行耗时分析
- 共耗时2.937秒, 而mysql查询耗时2.612秒 （只能看出这些）
2. arthas 进行接口内部调用路径的追踪和耗时统计
- 从Controller入口开始分析
从结果可以看到99.7%耗时都在真实的业务方法上,查看代码即: com.datacompass.live.service.pc.impl.PcLiveOverviewServiceImpl.rankList
trace com.datacompass.live.controller.pc.room.PcLiveOverviewController rankList -n 10
2. 追踪com.datacompass.live.service.pc.impl.PcLiveOverviewServiceImpl rankList (行:187 )
从下图可知95.08%的耗时都在com.datacompass.live.service.datawarehouse.impl.PlatformLiveStatHourV2ServiceImpl.getFormatRoomRank
trace com.datacompass.live.service.pc.impl.PcLiveOverviewServiceImpl rankList -n 10
- 继续追踪getFormatRoomRank
96.46%的耗时都在com.datacompass.live.service.datawarehouse.impl.PlatformLiveStatHourV2ServiceImpl.builderLiveRoomRankRespVO方法
trace com.datacompass.live.service.datawarehouse.impl.PlatformLiveStatHourV2ServiceImpl getFormatRoomRank -n 10
2. 分析builderLiveRoomRankRespVO的代码
a. 该方法执行了2次sql
b. 该方法的外层是个循环，加剧了这个问题
c.外层是一个不分页的直播间再次加剧了这个问题, 外层23个直播间，这里就有46个sql要执行
三. 问题解决
- 减少sql查询次数, 在最外层一次sql查出整个流程所需的结果。batchLiveTimeMap 一个map就足够下面的流程使用了。
四. 问题处理效果
降低到了300毫秒，符合预期
