一次接口耗时调优

less than 1 minute read

记录一次接口耗时调优过程和体会。

某次发版后,一个接口耗时上涨了很多,从90分位数看增长了几百毫秒。

通过查看代码变更,发现增加了一些数据库操作和网络请求,但是以为这些操作不至于引起如此大的性能损耗,就没有太在意。后来事实证明自己还是图样。

尝试在测试环境中打印部分函数的耗时日志来定位问题,然而没有什么收获。

最后在部分函数里加了一些耗时指标,重新发版,并制作了监控面板。 观察耗时曲线后才看出是其中一个此次变更中新增的函数里有查数据库的操作,而这个查询操作没有建对应的索引,而且这个表的数据多达几十万行,查询速度慢。 这个问题之所以没有在测试环境中暴露出来,是因为线下数据库的数据量比线上少了几十倍,看不出查询耗时的影响。


个人的一点体会:

  1. 维护好 changelog, 包括代码,配置,依赖(数据库、中间件等)的变更历史
  2. 细粒度的指标或日志(良好的可观测性)
  3. 有些线上问题在线下环境可能复现不出来,因此不能完全“相信”线下环境所体现出来的信息
  4. 局部引入的一点性能消耗可能会经由for循环将损失放大

优化办法:

  1. 通过添加恰当的索引等方式优化数据库查询速度
  2. 批量查询替代循环里逐次查询

Comments