解决性能回归

为了保持 Fenix 的良好状态，性能团队每周运行多次性能测试以识别回归。结果保存在 这里 并进行维护。

主要测试包括：

  • MAIN 首帧：模拟 COLD MAIN（应用程序图标启动）启动以报告 FullyDrawn，例如，当用户在启动应用程序后看到应用程序完全绘制时。

  • COLD VIEW 导航开始：应用程序链接启动以加载页面。它测量直到“导航开始”，这是一个内部 Gecko 事件，指示我们开始加载页面。

性能回归报告后的操作。

每周之后，性能团队运行测试，如果存在任何回归，他们将创建一个工单，提供上次非回归版本和回归版本之间的日期（示例 工单）。**这些日期对我们来说非常重要**，以便我们发现哪个提交引入了回归。由于我们希望识别哪个提交是导致问题的提交，我们需要对从非回归版本到回归版本的提交范围进行二进制搜索。幸运的是，性能团队有一个可以帮助我们的工具，它被称为 backfil。

该工具可以接收提交范围的开始/结束提交，构建所有 APK，运行性能测试，并提供与 这里 绘制的相同数据。通过它，我们可以识别出导致问题的提交。

安装所需的依赖项。

  • 拉取 perf-tools 仓库，并在其中按照 配置说明 进行操作。

  • 确保您可以在终端中运行 adb，因为我们通过脚本使用性能工具。

查找导致回归的提交。

现在您已安装所有依赖项，我们需要找到提交哈希值，即报告回归的提交和不存在回归的提交，因为 backfill 需要它们作为参数。

在报告的 工单 中，性能团队提供了回归引入的日期（5/10）以及不存在回归的日期（5/9）。

image

我们可以通过下载 Task Cluster 中的 APK 并转到“关于”页面来查找每个提交哈希值日期。

例如：

**对于 05/10**。 https://firefox-ci-tc.services.mozilla.com/tasks/index/mobile.v2.fenix.nightly.2022.05.10.latest/armeabi-v7a

image

从中，我们可以在发现回归时找到 2f7f5988f。

**对于 05/09**。 https://firefox-ci-tc.services.mozilla.com/tasks/index/mobile.v2.fenix.nightly.2022.05.10.latest/armeabi-v7a

image

当回归不存在时 98455c01e

使用这些提交，我们可以构建以下范围：https://github.com/mozilla-mobile/fenix/compare/98455c01eeba7c63775f18817cd079f5d08b4513…2f7f5988fccad2cf2043eed4b6849b32a4c76048 commit range

通过它，我们可以看到每个可能引入回归的提交。

使用 backfill.py

使用我们上面找到的信息，执行 backfill.py

perf-tools-main % python3 backfill.py --tests cold_main_first_frame --startcommit 98455c01eeba7c63775f18817cd079f5d08b4513 --endcommit 2f7f5988fccad2cf2043eed4b6849b32a4c76048 --git_remote_name https://github.com/mozilla-mobile/fenix.git --repository_to_test_path ../fenix fenix nightly armeabi-v7a commitsRange

其中：

  • **cold_main_first_frame**：是我们想要运行的测试，我们还可以根据回归类型传递 cold_view_nav_start。

  • **–startcommit**：是回归之前的提交。

  • **–endcommit**：是出现回归的提交。

  • **–repository_to_test_path** 是本地 Fenix 仓库的路径。

**注意**：确保您的仓库包含我们发布版本中包含的所有令牌（Sentry、Nimbus 等），因为不添加它们可能会影响测试结果，因为我们希望 APK 与 普通用户体验 相同。这部分包括确保您在 local.properties 中具有 autosignReleaseWithDebugKey。

🕐 请耐心等待，因为我们需要为范围内的每个可能的提交构建一个 APK，对于此范围，有 19 个提交，然后我们将构建 19 个 APK，并为每个 APK 运行性能测试。

随着脚本的进行，我们将在 perf-tools **目录**中看到一些活动，因为每个 APK 将以 apk_commit_<HASH>.apk 的格式保存在其中。

image

构建完所有 APK 后，脚本将继续进行测试阶段，它将为每个提交/APK 运行测试，并创建一个名为 backfill_output 的目录，在其中将为每个提交创建两个 **.txt 文件** apk_commit_<HASH>-cold_main_first_frame-analysis.txt 和 apk_commit_<HASH>-cold_main_first_frame-durations.txt

image

这些文件是脚本的输出：

  • **Cold_main_first_frame-analysis.txt**：将包含有关测试结果的关键信息，例如最大值、平均值、中位数和最小值。

  • **Cold_main_first_frame-durations.txt**：将包含每个测试重复的原始信息。

使用这些文件，我们可以通过逐个文件检查哪些结果更接近回归工单中报告的结果来识别哪个提交引入了回归。

找到导致回归的提交后，我们只需更新工单，发布我们的发现并标记引入该提交的人员，以研究如何优化补丁。通常，如果回归很严重，我们将要求撤消该提交，直到补丁得到优化。

额外提示：

  • 如果您想为特定 APK 运行与 backfil 通过运行的相同测试，可以在 这里 找到更多信息。

  • 如果您想绘制结果图表，可以使用 python3 analyze_durations.py --graph results.txt。*请记住，性能团队提供的结果来自在 Moto G 5 上运行测试。在更强大的设备上运行可能会导致结果出现偏差。*

  • 如果您需要在启动时开始记录配置文件，请访问 https://profiler.firefox.com/docs/#/./guide-startup-shutdown?id=firefox-for-android。

识别回归的来源。

当我们寻找性能回归时，我们的主要任务只是识别有问题的提交，但如果我们想弄清楚确切的原因，我们需要从回归版本和之前的版本中获取 配置文件，以尝试识别可能导致问题的原因，检查导致回归的提交的代码路径可以为我们提供一些查找线索。