巧用“火焰图”快速分析链路性能

火焰图（Flame Graph）是由 Linux 性能优化大师 Brendan Gregg 发明的用于分析性能瓶颈的可视化图表，它以一个全局的视野来看待时间分布，从顶部往底部列出所有可能导致性能瓶颈 Span。

背景阅读：

<The Flame Graph --Brendan Gregg>

<关于 Traces 、Span 等链路相关概念的介绍 --OpenTracing>

🔥火焰图是什么？

火焰图（Flame Graph）是由 Linux 性能优化大师 Brendan Gregg 发明的用于分析性能瓶颈的可视化图表，它以一个全局的视野来看待时间分布，从顶部往底部列出所有可能导致性能瓶颈 Span。

下面以一个系统可用性监测工具（观测云）的火焰图为例，陈述其绘制逻辑：

​● 纵轴（Y轴）代表调用 Span 的层级深度，用于表示程序执行片段之间的调用关系。上面的 Span 是下面 Span 的父 Span 。（数据上，可以通过子 Span 的 parent_id 等于父 Span 的 span_id 关联起来）

● 横轴（X轴）代表单个 Trace 下 Span 的持续时间（duration）。一个格子的宽度越大，说明该 Span 从开始到结束的持续时间越长。[1] 只要有“平顶”（plateaus），则表示该函数可能存在性能问题，就可能是造成性能瓶颈的原因。

🔥🔥 为什么要用火焰图？

通常，我们可以通过查询日志、使用Shell等协助定位问题异常原因 ；再细致一点，会用到Jmap、Jstack分析堆栈跟踪（Stack Trace）等。但若需要分析至堆栈、调用链的阶段，说明很可能已经是 Performance的问题了[2] 。但上述方法，或将产生海量文本无法直观分析，或缺乏汇聚型数据难以综合评判，降低了我们排查问题的效率。

因此，为了降低人工二次分析难度、提高性能数据的易懂性，火焰图便被广泛用于分析性能瓶颈问题。它纳入了线程栈的调用链和出现频率两个维度，从而可以非常方便地看到顶层的哪个函数占据的宽度最大，即性能资源都消耗在了哪里；进而，能够直观地定位程序的性能瓶颈，以进行相应地优化。

🔥🔥🔥巧用观测云火焰图分析链路性能？

观测云提供的火焰图除了展示函数调用的基本性能信息之外，还在同一个可视化图表中关联了多维度数据，支持用户综合评判性能瓶颈的原因所在。

1 、火焰图

火焰图左侧图示区：

• 同一种颜色的 Span 对应同一个服务（service）：可直观感知当前 Trace 所涉及到哪些服务请求。（小提示：服务的颜色会继承到链路查看器等其他分析页面）

• 每一个Span 块默认显示：当前 Span 的资源（resource）或操作（operation）、持续时间（duration）、以及是否存在错误（status = error）；悬浮还可展示其整体耗时占比。

• 对于多线程或者异步任务：同层级或下属子 Span 执行时间可能会出现重叠，图中通过连线的形式来关联父子 Span 之间的关系。（相关细节可参考观测云帮助文档<巧用“火焰图”快速分析链路性能>）

火焰图右侧服务列表：

显示当前 Trace 内发生请求调用，所涉及到的服务名称和颜色、该服务执行时间占总执行时间的百分比。（注意：服务名称显示为 None 的情况，则表示当前 trace 未找到 parent_id = 0 的顶层 Span）

2 、Span 列表

​

图1 全收起状态，以服务视角：

显示服务类型、名称和颜色，以及当前服务下是否存在 status = error 的 Span；还依次显示当前服务下面的 Span 数量、持续时间（duration）的平均值、执行时间总和，以及当前服务的执行时间占总执行时间的百分比。

​

图2 服务行展开后，以 Span 视角：

显示资源名称（resource）、对应服务颜色及当前 span 是否存在 status = error ；还依次显示当前 Span 持续时间（duration）、执行时间数值及占总执行时间的百分比。

3 、服务调用关系

​显示当前 Trace 下服务之间的调用关系拓扑：

• 支持按资源名称（resource）模糊匹配，定位某个资源的上下游服务调用关系。

• 服务 hover 后，显示当前服务下的 Span 数量、服务执行时间及占比。

---

下面以观测云为示例，展示如何通过火焰图进行“性能瓶颈”的分析。

1、注册与安装

在观测云，登录你的账号～

2 、实际链路数据分析

第一步：登录观测云工作空间，查看应用性能监测模块的服务列表，从服务页面已经可以看出 browser 服务的 P90 响应时间较长。

第二步：点击 browser 服务名称，查看该服务的概览分析视图，可以看出影响当前服务响应时间的最关键的资源是 query_data 这个接口，因为这个接口是观测云的一个数据查询接口，所以接下来我们看下这个接口在查询过程当中，到底是因为什么导致耗时较长。

第三步：点击资源名称，跳转到查看器，通过点击 持续时间 倒序查看响应时间的最大值。

第四步：点击 Span 数据，查看分析当前 Span 在整个链路里面的执行性能和其他相关信息。

​

第五步：点击右上角 [全屏] 模式按钮，放大查看火焰图相关信息。结合整体链路查看，可以看出 browser服务在整个链路中的执行时间占比高达 96.26%，从 Span 列表也可以得出此结论。根据火焰图的占比和对应的链路详情信息，我们可以总和得出 browser 的这个 query_data Span 在整个执行过程中可以看到 resource_ttfb（资源加载请求响应时间）耗时 400 多毫秒， resource_first_byte（资源加载首包时间）耗时 1.46 秒，再结合查看 province 的地理位置定位是 Singapore（新加坡），而我们的站点部署在杭州节点，则可以得出是因为地理位置问题导致数据传输的时间变长从而影响了整个的耗时。