记一次接口超时

近期,收到线上告警,某个接口在中午12点时,突然超时了。

Skywalking/ Arthas 查看接口的耗时

Skywalking/ Arthas 都可以查看接口内各个方法的耗时。
一般情况下,查看到耗时的方法,

  • 看下sql 语句,查看执行计划EXPLAIN ,有没有加索引,有没有慢sql。
  • 看下查询的代码,有没有加缓存。加缓存可以提高查询速度。
  • 看下代码里有没有在循环里面调用数据库/缓存,如果有可以改成批量处理、异步处理。
  • 再看下代码里有没有发送短信,发送邮件等耗时操作,能否改用异步处理。

如果没有 Skywalking/Arthas ,也可以通过 StopWatch 进行分析。
详情见: https://blog.csdn.net/sinat_32502451/article/details/133026521

结果,这一次查看了这个接口的耗时代码,发现逻辑简单,只有一个 sql 语句,而且已经加索引了, EXPLAIN 后发现sql语句并没有慢 sql。
那说明超时,有可能并不是这个接口本身的问题。

查看 QPS

打开阿里云,通过阿里云的 WAF 功能,查看 QPS。 接口超时的时间段,QPS 是不是比平常高。

查看 Request rate (请求速率)

打开 grafana, 查看 Request rate,发现在这个接口超时的时间段,系统另一个接口的 Request rate 非常高,占用了大量的数据库连接池,导致了这个接口超时。

posted on   乐之者v  阅读(22)  评论(0编辑  收藏  举报

相关博文:
阅读排行:
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· DeepSeek 开源周回顾「GitHub 热点速览」
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
历史上的今天:
2023-07-07 需求评估-不同数据量和场景的技术选型
2016-07-07 android笔记:BroadcastReceiver
2016-07-07 android学习笔记
< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5

导航

统计

点击右上角即可分享
微信分享提示