性能测试概览

注意

此页面仍在构建中，缺少视频。

在本文档中，您将找到有关产品性能测试基础知识的所有信息。还提供了一组视频和说明，以指导您了解与性能测试相关的各种主题。如果您是性能测试新手，从第一部分开始将对您最有所帮助。

救命！我遇到回归了，该怎么办？

大多数人在 Mozilla 中首次接触性能测试都是通过类似这样的 Bug：

Bug 的标题将包含导致最大变化的测试和子测试、检测到变化的平台以及日期。它还将以变化大小（百分比）的范围作为前缀。在 Bug 详情中，触发警报的 Bug 也将在 Regressed by 字段中找到，并且补丁作者将需要提供信息。

Bug 概述和第一个评论（也称为评论 0）

性能回归 Bug 的第一个评论（评论 0）中始终会找到警报汇总表，它提供了理解哪些内容发生回归所需的所有信息。

• 在警报的第一句话中，提供了导致警报的实际推送/提交的链接。

• 在其下方，显示了一个汇总回归和改进的表格。

• 表格的每一行都提供了一个检测到的回归/改进。

  • Ratio：提供变化的大小，并链接到指标的图表。

  • Test：发生变化的测试和指标的名称。它链接到测试的文档。

  • Platform：检测到变化的平台的名称。

  • Options：指定测试运行的条件（例如，冷启动、热启动、字节码缓存）。

  • Absolute Values：变化的绝对值。

  • Performance Profiles：测试的 Gecko 配置文件（在测试前和测试后）（并非所有测试框架都提供此功能）。

• 在表格下方，可以找到一个 alert summary 链接，它提供了此表格的不同视图，此处提供了对警报汇总链接的完整深入解释 Perfherder 警报视图。此处还可以找到一些其他调试信息，例如 side-by-side 视频。它还将包含在此 Bug 提交后触发的任何其他测试。

• 然后提供了一些关于我们对补丁作者的期望的信息，包括他们在警报被撤回之前需要响应警报的时间以及处理回归的指南链接。

• 最后，提供了一个有用的命令，使用 ./mach try perf --alert <ALERT-NUM> 在 try 上运行这些测试。 请参阅此处以获取有关 mach try perf 的更多信息。

从警报汇总评论中，可以验证多件事：

• 检查图表以确保回归/改进非常明显。

• 查看警报汇总以查看是否有任何可用的并排视频进行可视化。

• 查看测试描述以了解测试正在执行的操作，以及发生变化的指标正在测量的内容。

• 比较前后性能配置文件以查看可能发生的变化。有关此内容的更多信息，请参阅 使用 Firefox Profiler 部分。

通过所有这些信息，可以执行两件事。首先是调查配置文件（或使用其他一些工具），并找到需要修复的问题。在调查和验证修复的过程中，将需要通过运行测试来验证修复。请转到 运行性能测试 部分以获取相关信息，然后转到 性能比较 部分以获取帮助在 CI 中进行性能比较，这对于验证修复是否可以解决警报是必要的。

其次是请求性能审查人员确认导致警报的补丁是否确实是正确的。当指标非常嘈杂且变化很小（在 2-3% 左右，我们的检测阈值）时，可能会发生这种情况。审查人员将对测试进行更多重新触发，并可能询问有关补丁的一些澄清问题。

这些警报 Bug 主要有 3 种解决方法，具体取决于您在调查中发现的内容：

1. 一个 WONTFIX 解决方法，这意味着检测到更改，但不会修复。即使 Bug 导致了回归，也可能使用此解决方法，但改进超过了这些回归。由于我们将其视为基线更改，因此与 Harness 相关的更改通常也以这种方式解决。

2. 一个 INVALID 解决方法，这意味着检测无效，并且性能指标没有变化。这些通常很少见，因为性能审查人员倾向于在生成 Bug 之前使警报无效，并且往往与基础设施更改或非常嘈杂的测试相关，在这些测试中无法准确确定罪魁祸首。

3. 一个 FIXED 解决方法，这意味着检测到更改，并且已进行修复以解决它。

如果您对警报有任何疑问，或者需要其他帮助来调试警报，请随时向报告 Bug 的性能审查人员索取信息。可以通过添加 status-firefox [X]: --- → affected 评论的用户在回归 Bug 上识别出最适合添加信息的人员。将来，此人 将在评论零中被识别。

Perfherder 警报视图

单击“警报汇总”超链接将带您进入 Perfherder 上的警报汇总表，如下面的屏幕截图所示：

• 该表每行包含一个性能指标，该指标要么提高了指标，要么降低了指标。

• 从左到右，作为开发人员，您需要注意的列和图标是：

  • Graph icon：带您到一个图表，显示指标的历史记录。

  • Test：所有测试设置、测试所有者及其联系信息的超链接。以及子测试的名称（在本例中为 SpeedIndex 和 loadtime）。

  • Platform：发生回归的指标的平台。

  • Debug Tools：可用于帮助可视化和调试回归的工具。

  • Information：历史数据分布（模态、正常或如果信息不足则为 n/a）。

  • Tags & Options：指定测试运行的条件（例如，冷启动、热启动、字节码缓存）。

  • Magnitude of Change：指标改进或降低了多少（绿色表示改进，红色表示降低）。

  • Confidence：指标的置信度值（数字不是 100）数字越大，置信度越高。

运行性能测试

性能测试可以在本地或使用 try 运行在 CI 中运行。通常，建议使用 try 运行来验证您的补丁（如果有）产生的性能变化。这是因为我们运行测试的硬件可能与本地机器具有不同的特性，因此本地测试可能并不总是产生相同的性能差异。使用 try 运行还可以使用我们的性能比较工具，例如 比较视图 和 PerfCompare。有关此内容的更多信息，请参阅 性能比较 部分。

尽管本地测试仍然可能重现 CI 中发现的更改，但这并不能保证。要在本地运行测试，您可以查看 Harness 文档测试列表中列出的测试，例如 Raptor 测试 的此列表。您将发现四种主要方法来运行这些测试：

• ./mach raptor 用于 Raptor

• ./mach talos-test 用于 Talos

• ./mach perftest 用于 Mozperftest

• ./mach awsy 用于 AWSY

还可以使用 ./mach perftest 运行所有警报测试。为此，请找到警报汇总 ID/编号，然后在以下命令中使用它：

./mach perftest <ALERT-NUMBER>

要运行与 CI 中运行的完全相同的命令，请添加 --alert-exact 选项。还可以使用 --alert-tests 选项指定要运行的测试。

性能比较

跨多个 try 运行比较性能指标是性能测试过程中的重要步骤。它用于确保更改不会降低我们的指标，以确定补丁是否产生了性能改进，以及用于验证修复是否解决了性能警报等其他事项。

我们目前使用 比较视图 来比较性能数据。在此过程中看到的第一个界面如下所示，用于选择两个要比较的推送（基于修订版）。

同时，需要选择要比较的框架。默认情况下，选择 Talos 框架，但在按下“比较”按钮后可以更改此设置。

按下“比较”按钮后，将显示比较的可视化效果。有关比较中各列含义的更多信息，请参阅 此文档。

使用 Firefox Profiler

Firefox Profiler 可用于帮助调试代码中的性能问题。 请参阅此处了解如何使用它 以更好地了解回归代码在哪里以及可能导致回归的原因。在大多数警报汇总 Bug 中，都会提供回归前后的配置文件（请参阅上面的第一部分）。

如果警报摘要中未提供这些信息，可以通过点击图表链接（警报摘要中的百分比变化率），选择图表中更改前后的一点，然后点击作业链接来为测试生成这些信息。然后，在 Treeherder 中打开作业面板后，选择Generate performance profile以启动生成性能配置文件的新任务。请参阅以下图表，其中说明了此过程。

此外，您也可以使用溢出菜单生成配置文件。

大多数 Raptor/Browsertime 测试在测试运行结束时默认会生成性能配置文件，但 Talos、MozPerftest 和 AWSY 测试不会生成。如前所述，对于回归/改进警报，您可以在注释 0 中找到这些配置文件的之前和之后链接。

您还可以在 Raptor 测试的工件选项卡中找到配置文件。

要在本地生成配置文件，您可以传递标志--extra-profiler-run或--gecko-profile，它们分别重复启用分析器的额外迭代测试，或从一开始就启用分析器运行三次迭代的测试。

添加性能测试

本节正在建设中。

其他帮助

请联系 Matrix 上的#perftest 频道或 Slack 上的 #perf-help 频道中的性能测试和工具团队。