使用 Sentry 做性能监控 - 分析优化篇

本文为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！

前言

在使用 Sentry 做性能监控时，有三个非常关键的环节：收集性能指标数据、对性能指标数据做分析、根据分析结果做优化。有了这三个环节，性能监控才能算是有了一条相对完整的链路。这三个环节中，关于性能指标数据的收集，小编已经在上一篇 使用 Sentry 做性能监控 - 原理篇 文章中做了详细梳理，剩下的性能指标数据分析和优化手段，小编将会在本文继续给大家梳理。

本文的目录结构:

怎样使用 Sentry 监控平台进行性能分析
性能分析自动推送
怎样做性能优化
结束语

怎样使用 Sentry 监控平台进行性能分析

当我们打开 Sentry 监控平台，切换到 Performance 面板，然后选择某一个项目时，可以看到以下界面:

简单操作一下这个界面:

Oct-04-2022 21-51-03.gif

在操作过程中，我们可以看到：

诸如 View Trends、Display: Frontend(Pageload)、Display: Frontend(Other)、Display: Backend 这样的操作选项；
诸如 p50 / p75 / p95、Apdex、Failure Rate、TPM、Throughput 这样的指标；
各种折线图、柱形图、表格；
其他；

那么问题来了。这些都有什么含义呢？和性能分析有什么关系呢？

和大家一样，小编刚开始看到这些内容时也是一筹莫展，不知道怎么理解这些操作、指标、图表。为了搞清楚这些内容的含义，只能去查阅官方文档，并结合实际项目动手操作去理解。经过几天的研究，总算有了一些眉目。

接下来，小编就把自己的一些收获分享给大家。

Display: Frontend(Pageload)

进入 Performance 面板以后，Dispaly 展示下拉选择框默认会选择 Frontend(Pageload)。

看到 Pageload，大家有没有觉得眼熟呢？

在上一章 使用 Sentry 做性能监控 - 原理篇 中，我们提到 Sentry 在上报性能指标数据时，会把数据分为首屏 - pageload 和页面切换 - navigation 两类。对应的，我们可以在监控平台中通过选择 Display: Frontend(Pageload) 和 Display: Frontend(Other) 来查看上报的两类数据。

选择 Display: Frontend(Pageload), 我们可以查看首屏(pageload)类型的指标数据。

当 Display 下拉框选择 Frontend(Pageload) 以后，整个 Performance 面板会呈现三块内容：

卡片区域， FCP、LCP、FID、CLS 四大指标在过去 24h 内的情况；
折线图 / 柱形图区域，用于统计 LCP 指标数据、性能监控吞吐量；
表格区域，统计不同路由在首屏时的 FCP、LCP、FID、CSL、TPM 指标数据；

其中，最核心的要数卡片区域。

卡片区域

卡片区域有 4 个卡片，展示了过去 24h 内 FCP、LCP、FID、CLS 四个指标的平均耗时，以及表现优劣的百分比。

关于如何评判 FCP、LCP、FID、CLS 表现的优劣，Sentry 提供了标准:

以 FID 为例，图中 FID 的平均耗时为 190ms，好 - good(绿色)占比 72%，意味着过去 24h 内 72% 的首屏 FID 耗时小于 100ms；待提升(黄色) - meh 占比 7%，意味着过去 24h 内 7% 的首屏 FID 耗时在 100ms 到 300ms 之间，需要优化；差 - poor(红色) 占比 22%，意味着过去 24 内 22% 的首屏 FID 耗时大于 300ms，非常糟糕。

通过查看 4 个卡片，我们发现 FCP、FID 这两个指标 meh、poor 的比例较高，需要特别去关注。

点击 FID 卡片，会进入对应的指标详情页面。

指标详情页面，分为折线图和表格两个区域。

先看折线图区域。折线图表示过去 24h 内 FID 的耗时情况。折线图中有黄、红两条水平虚线，分别代表 meh 和 poor。有了这个折线图，哪个时间段 FID 耗时较久以及具体耗时情况就可以一目了然。

表格区域，是不同路由在首屏时 FID 数据的汇总。

表格的表头中有几项需要重点关注 - P50(FID)、P75(FID)、P95(FID)、STATUS：

STATUS 代表各个路由在首屏时 FID 的表现情况，有 poor、meh、good 三个值。点击表头，可以进行升序 / 降序排序。
P50、P75、P95 是百分位数值，表示从过去 24h 的所有 FID 数据中，挑选出50%(75%、95%) 位置的数据。(挑选之前，要先对数据从小到大排序)。

百分比数值是统计学中的一种术语。通俗来讲，就是将一组数据从小到大排序，并计算相应的累计百分位，则某一百分位所对应数据的值就称为这一百分位的百分位数。例如，将一组 100 个数值按从小到大排列，P50 是 index 为 50 的数值，P75 为 index 为 75 的数值， P95 为 index 为 95 的数值。

提个问题，为什么这里要使用百分比数值统计呢？

要回答这个问题，我们需要先看看统计数据的另一种方法 - 平均值。

平均值统计方法，是我们最常用的统计方法，计算简单方便。不过，这种统计方式存在一个非常大的问题，就是它会把一些异常数据平均掉，进而会掩盖一些异常问题。例如平均 FID 为 340ms，但是具体有多少个请求比 340ms 要大，又有多少个请求比 340ms 要小，大多少，是 200 ms，还是 500ms，又或是 1000ms，我们无从得知。

要想解决这个问题，就需要借助百分比数值方法了。例如，FID 平均时间为 150ms， P50 为 29.61ms， P75 为 169ms， P95 为 600ms。这表示我们的首屏 FID 耗时，百分之 50 在 30 ms 以内，百分之 50 在 30ms 以外；百分之 75 在 170ms 以内，百分之 25 在 170ms 以外；百分之 95 在 600 ms 以内，百分之 5 在 600 ms 以外。

这样有了更加精准的统计信息，我们就可以更好的去针对异常数据去做分析。

在表格中选中 /aicc/task/manual 这条数据，然后点击，会进入指定路由对应的详情页面。

在这一页面中，我们重点关注中间的表格区域。

表格区域是指定路由在首屏期间的数据上报记录汇总，并且上报的性能指标汇总包含 FID。表格有四个过滤条件: Recent Transactions、Slow Transactions(P95) 、Outlier Transactions(P100)、Fastest Transactions，分别对应最近 24h 内的上报记录(按时间排序)、最近 24h 内上报记录的前 95% (按首屏时间从大到小排列)、最近 24h 内上报记录的前 100%(按首屏时间从大到小排列)、最近 24h 内耗时最短的记录(按首屏时间从小到大排列)。

指定过滤条件为 Recent Transactions，然后任选一条记录点击，计入上报记录详情页面。

在详情页面中，我们可以看到路由为 /aicc/task/manual 的首屏加载详情。通过分析首屏加载的各个过程，就可以知道为什么 FID 耗时较长了，然后做针对性的性能优化。

折线图、柱形图区域

折线图、柱形图区域，用来展示过去 24h 内 LCP 和性能监控上报数据吞吐量的情况。

表格区域

表格区域，是不同路由在首屏时 FCP、LCP、FID、CLS 数据的汇总。

我们可以选中任一条数据，进入到指定路由的详情页面。

然后选中任一条上报数据记录，进入到上报数据详情页面。

在详情页面，我们可以通过分析首屏加载的各个过程，看到底是哪个阶段出现异常导致首屏耗时较久，然后做针对性的性能优化。

Display: Frontend(Other)

选择 Display: Frontend(Other), 我们可以查看 navigation 类型的指标数据。

此时， Performance 面板分为两个区域：

折线图、柱形图区域；
表格区域；

折线图、柱形图区域

折线图、柱形图区域，用来展示过去 24h 内各个时间段页面切换耗时的 P50(P75、P95)值以及各个耗时对应的上报记录数。

表格区域

表格区域，统计不同路由页面切换耗时的 P50(P75、P95)值以及吞吐量情况。

我们可以选中任一条数据，进入到指定路由的详情页面。

然后选中任一条上报数据记录，进入到上报数据详情页面。

在详情页面，我们可以通过分析页面切换过程中各个接口的调用情况，找到有异常的接口调用，然后针对性的做性能优化。

Display: Backend

选择 Display: Backend, 我们可以查看性能监控数据上报的汇总统计。

此时， Performance 面板分为 3 个区域:

卡片区域；
折线图、柱形图区域；
表格区域；

卡片区域

卡片区域，用来统计和性能数据上报相关的 Throughput、Failure Rate、Apdex 和页面加载耗时的 P75 值。

Apdex，application performance index，应用性能指标，用于根据应用程序响应时间跟踪和衡量用户满意度。分数越高，代表用户满意度越高，最高可到 1.0，即 100% 的用户有满意的的体验。该指标提供了一个标准来判断应用性能。

Apdex 的计算方式:

T，规定一个响应时间的阈值；
Satisfactory，当响应时间 <= T 时，表示用户满意；
Tolerable， T < 响应时间 <= 4T, 表示用户可以接受；
Frustrated， T > 4T, 表示用户无法忍受；
计算过程： (满意数量 + 接受数量 / 2) / 所有的数量;(这个公式很好理解，Tolerable，有些用户可以接受，就有些用户不可以接受，所以要除以 2)。

阈值 T 可以在 project -> performance -> response time threshold 中设置:

failure_rate, 不成功事务的失败率。Sentry 将状态不是 ok、cancelled、unknown 的事务视为失败。

Throughput，吞吐量：

Total, 总的吞吐量，即过去 24h 内总的数据上报记录数；
TPM, 每分钟的平均事务数，即每分钟数据上报记录数；
TPS, 每秒钟的平均事务数，即每秒钟数据上报记录数；

折线图、柱形图区域

折线图、柱形图区域，用来展示过去 24h 内各个时间段页面切换耗时的 P50(P75、P95)值、各个耗时对应的上报记录数、TPS、Failure Rate。

表格区域

表格区域，统计不同路由页面切换耗时的 P50(P95)值、Apdex、Failure Rate、TPM。

我们可以选择任一条数据，查看指定路由页面切换的详情。

View Trends

在性能主页中，我们可以通点击右上角的 View Trends 按钮来找到趋势视图。通过趋势视图，我们可以找到随着时间的推移，性能发生重大变化的情况。

整个页面分为两个部分。左侧表示性能出现提升，右侧表示性能出现下降。通过这两个折线图，我们就可以知道我们的性能优化是否有起到作用。

性能分析自动推送

知道了怎么使用 Sentry 监控平台的 Performance 面板做性能分析还不够，我们还需要像异常监控一样，配置一个告警推送，自动将性能异常告警推送给指定的负责人。

具体配置如下:

打开 Alerts 面板，然后点击 Create Alert Rule 按钮，进入选择告警页面。

我们可以选择 Performance -> Largest Contentful Paint，配置一个 LCP 异常告警。
点击 Set Conditions 按钮，进入告警配置页面。

这里，最关键的是要配置第 4 步 - Set thresholds to trigger alert 和第 5 步 - Perform actions。
点击 Save Rule 按钮，保存配置好的告警规则。

这样，一个能自动推送性能异常的告警就配置好了，是不是非常简单呢，😄。

怎样做性能优化

有了分析结果，接下来就是根据分析结果来做性能优化了。这是最后一步，也是最关键的一步。

在做性能优化时，不同的性能指标，会有不同的优化手段。这里，小编先给大家列举一下常见的性能指标对应的优化手段。

为了能让用户更快的看到页面内容，我们需要优化 FCP 和 LCP。

优化 FCP，我们通常可以采用这些手段:

减少服务器响应时间 - 避免多次重定向、提前建立连接 preconnect、dns 预解析、http2、使用高效的缓存策略、使用 CDN、使用 SSG 代替 SSR；
优化资源加载速度 - 预加载关键资源、压缩 js / css / 图片等静态资源、移除未使用的资源；
延迟加载未使用的资源 - defer / async、懒加载；
减少 js 的阻塞渲染 - 尽早开始页面渲染、使用 worker；
在请求数和请求文件大小之间，寻找一个最佳平衡点；
避免 DOM 过大；
减少关键请求的深度；

LCP 的优化和 FCP 有稍许不同。除了上面的优化手段以外，我们还可以将客户端渲染改为服务端渲染，提前将页面主体渲染出来。但是这会引发新的问题，即如果采用 SSR，那么有可能会导致服务器响应时间变长, 导致 FCP 性能变差。不过在首屏性能测试中，LCP 的占比要比 FCP 更高，如果能有效提高 LCP，适当降低 FCP 也是可以的。

另外，为了能让用户更早、更流畅的操作页面，我们优化 FID、TTI、TBT 指标。

优化 FID、TTI、TBT，最关键的是减少 js 的阻塞时间。具体的手段有:

优化资源加载速度 - 预加载 js 资源、压缩 js 大小、使用 CDN、使用缓存；
减少 js 执行时间 - 延迟加载未使用的 js、使用 worker；
减少关键请求的深度；

此外，为了能让用户有更好的视觉体验，我们还需要优化 CLS 指标。

优化 CLS，我们可以采用这些手段:

提前确定好 img、视频等节点的大小尺寸；
除非是对用户交互做出响应，否则切勿在现有内容的上方插入内容；
首选 transform 动画，而不是触发布局偏移的属性动画；

结束语

到这里，关于如何使用 Sentry 做性能分析和优化就结束了。

简单做一下总结，本文重点梳理了如何使用 Sentry 监控平台的 Performance 面板做性能分析、如果自动推送性能监控异常数据、常用的性能优化手段，再结合 使用 Sentry 做性能监控 - 原理篇 一文中讲到的性能监控的原理，相信大家对如何使用 Sentry 做性能监控已经有一个初步的了解吧。

由于小编水平有限，可能有些地方没有梳理清楚或者错误，欢迎大家在评论区指正哈。