跳到主要内容

用alinode的trace来跟踪性能问题

· 5 分钟阅读
月子喵

上篇找到了项目中的一个性能问题, 本篇就来实战一下 trace

file_6542092
Preview

安装​

按照 Trace 链路追踪 文档, 安装依赖

加载中.....

不过这个库没有types. 可以使用我的fork haozi23333/opentracing, 增加了 types, ts 用起来更顺滑

安装的话使用

加载中.....

给原项目提了pr, 但是这玩意内部用了一个获取本地ip的库 internal-ip 在 travis-ci 上获取不到IP, 导致 ci 过不去 (上一次通过ci是在3年前), 导致现在无法合并, 就离谱

埋点​

本项目用的是 Nest.js , 只对一个觉得有问题的接口进行了埋点, 如果需要对大部分的接口埋点, 建议写一个中间件, 自动创建父Trace

加载中.....

要注意一定要添加HTTP_METHOD, HTTP_URL, HTTP_STATUS_CODE 这个三个tag, 不然平台会丢弃这个数据

之后就是启动项目了

效果​

Preview

有点离谱, 在晚上高峰期, 平台运行任务的时候, 最长的一个请求竟然高达1.68s

重新拆分了统计子任务消耗情况, 生成的图表

image-20201226014153553
Preview

分析了一下代码, 这个特殊请求里面有 (数据库为 MongoDB)

  • findOne 4+次
  • aggregate 20+次
  • redis keys 15+次(总数不多)

这个请求干的事情确实有点多, 而且都是串行的, 没做缓存也没做并行, 数据即使没做变动, 也会去 aggregate动态计算

不过没啥难度, 优化完成之后, 已经不会在上面显示了

有点奇怪的是, logEvent 这个函数, 其实会记录一个 startTimeFromFullTrace的时间, 但是这个Logs上面 没有任何表示(F12看数据里面也有有的)挺遗憾的, 要是也有个时间轴就好了

image-20201226012427572
Preview

任意函数埋点​

加载中.....

后~​

还没遇到过真实的大项目出现性能问题..., 能想到的就是做个灰度发布, 放部分流量进来跟踪一下,