DevTools 性能维护¶
每周，我们应该审查
PerfHerder 警报¶
设置¶
首先请记住，此 DevTools 文档仅突出显示 DevTools 工作流程的具体内容。DevTools 团队正在对其自身的性能警报进行分类，并遵循略微简化的工作流程，但总的来说，整个性能维护文档也适用于此。
请查看性能维护文档和工作流程文档。您还应该加入 https://chat.mozilla.org/#/room/#perfsheriffs:mozilla.org 的性能维护聊天室。
DevTools 文档不会解释如何使用 PerfHerder 或 TreeHerder，但我们会尽量链接到相关的文档（如果可能）。
为了维护 DevTools 警报，您的 Treeherder 用户需要属于性能维护组，否则您将无法更新警报。查看文档以请求访问权限，您可以参考以前的 Bug作为示例。
DevTools 警报¶
性能测试是一种特殊的测试，它输出一组指标（时间、内存），这些指标由 Perfherder 随时间推移收集。当检测到其中一个指标的显着差异时，系统会自动创建警报。
DevTools 性能测试的列表记录在DevTools 性能测试概述中。在此列表中，大多数警报都与 DAMP 或内存泄漏测试相关。
每周维护¶
未分类的 DevTools 警报列在https://treeherder.mozilla.org/perfherder/alerts?status=0&framework=12&hideDwnToInv=1&page=1。每周维护任务的目标是对所有这些警报进行分类。
对警报进行分类并不意味着解决性能问题，而仅仅是确认警报并：
提交 Bug
或标记为“不会修复”
或标记为“改进”
作为后续步骤，应向团队展示最显着和可操作的警报，并决定下一步行动。完全可以认为性能回归不值得调查或修复，并因此关闭 Bug。
工作流程建议¶
没有正确或错误的方法来维护警报，很多方面将取决于您自己的判断和对代码库中近期更改的了解。但是，以下是一些有助于分解任务的步骤。
忽略次要或无效的更改¶
DevTools 测试可能会受到许多平台更改的影响，这些更改有时会更新子测试基线几个百分点。如果更改很小（例如小于 5%）并且推送日志不包含任何 DevTools 更改，您可以确认测试回归并将警报标记为“不会修复”。
我们通常还避免过多关注“关闭”测试，这些测试测量在使用面板后关闭工具箱所需的时间（例如“complicated.styleeditor.close.DAMP”）。这些测试通常很嘈杂，并不是我们投入大量精力的地方。除非出现巨大回归，只要这些测试在几十毫秒内运行，您可以跳过它们。
重新组合警报¶
我建议尝试重新组合可能由相同更改引起的警报。您可以通过以下几个标准识别它们：
警报的日期时间应该接近（例如同一天，相隔几个小时）
警报的区域应该相似（例如，仅调试器测试受到影响，仅内存测试受到影响）
不同的警报是关于不同的平台
鉴于 DevTools DAMP 测试的嘈杂性，经常发生的情况是，例如，会分别为 Linux 和 Windows 上的不同构建生成警报。根据您对上周发布内容的总体了解，您可以查看相似警报的推送日志，并查看是否发现所有相似警报中都存在 DevTools 更改。
一旦您确定了需要重新组合的两个警报，请使用“重新分配”功能合并警报。
调查警报¶
如果警报有效且应进行调查，您应该确认警报并提交 Bug，使用“提交 Bug”功能。
创建 Bug 后，使用“链接到 Bug”功能将 Bug 链接到 Perfherder 上的警报。然后，我们还可以进行一些初步调查。
您可以查看警报的推送日志，以查看是否有任何发布的补丁似乎与之直接相关。
查看哪些平台发生了回归，以了解回归是否影响了所有平台（Windows、Linux、macOS）。通常，来自 DevTools 更改的回归将影响所有平台，因此仅影响 macOS 的警报可能表明回归更可能来自平台更改。
了解哪些测试发生了回归。如果多个平台报告了相同的问题，则在视觉上解析列表可能会很困难。使用“筛选”输入仅查看一个平台的测试，例如“linux1804-64-qr”。然后，您应该能够确定我们的哪些测试区域发生了回归。
在为警报提交的 Bug 中总结此信息，并将其添加到每周 DevTools 工具签到议程中。您也可以在警报的备注中添加一些信息。
除非您已经确定了导致回归的更改集，否则您还应该从警报的作业开始进行回填。从 Perfherder 中点击作业链接，这应该会将您引导至 autoland 中的 DAMP 作业。使用自定义操作为之前的 10 个 autoland 作业开始回填，重新触发 5 次。
关于改进的说明¶
如果警报仅包含改进，您仍然应该检查改进是否预期，尤其是在它是重大更改的情况下。否则，这可能表明测试不再测试它应该测试的内容，应该进行调查。除非预期改进，否则我们应该遵循与任何警报完全相同的工作流程。
警报备注和警报所有者¶
这适用于您正在分类的所有警报。尝试为未关联 Bug 的警报添加备注。备注可以是简短的解释，说明为什么忽略警报，或特定改进可能来自哪里。并使用“获取”按钮将自己分配到警报。
Perfherder 提示¶
再次请参考Perfherder 的主要文档。但是，您可能会遇到 DevTools 工作流程中的一些 UX 问题，值得指出。
无法更改警报的状态¶
每个警报列出了几个可能已改进或发生回归的测试。警报和测试都有状态，例如“未分类”、“无效”等。警报的状态似乎部分源自各个测试的状态。有时，正确更新测试状态或警报状态可能很困难。
一个常见的问题发生在重新组合警报之后。此时，移动到另一个警报的测试将获得“已重新分配”状态。假设您想将此警报中的所有测试移动到“已确认”。如果您使用警报标题左侧的复选框选择所有测试，您将看不到“确认”测试的按钮。这是因为您无法将测试从“已重新分配”状态移动到“已确认”状态。相反，在这里，您必须仅选择“未分类”测试。您可以通过在复选框旁边的下拉列表中选择“未分类”来轻松做到这一点。一旦您只选择了未分类的测试，您应该能够按预期更改其状态。并且，仅包含“已重新分配”和“已确认”测试的警报将被视为已确认。
有时，警报似乎也没有在右上角的下拉列表中提供预期的操作。在这种情况下，最好在https://chat.mozilla.org/#/room/#perfsheriffs:mozilla.org 上提出此问题，但您也可以尝试重置警报中的测试，看看是否可以解除状态阻止。
已分类的警报再次出现¶
有时，已分类的警报将被分配新的测试更改（回归或改进）。此新测试很可能具有“未分类”状态，这将使警报回到未分类类别。如果警报看起来很熟悉，请注意日期并检查各个测试的状态，可能只是添加了一些新测试，需要为其分配与其他测试相同的状态。
DevTools 性能仪表盘¶
我们过去主要依赖 DevTools 性能仪表盘进行监控，但现在警报是我们检测回归或改进的主要方式。但是，DevTools 仪表盘仍然提供了一种很好的方法来在一个中心位置可视化 DevTools 性能随时间的变化。
DevTools 仪表盘依赖于与警报相同的 Perfherder 数据，因此我们不应期望从此工具中收集太多新信息。使用的数据来自 mozilla-central 上运行的测试，Windows 平台上的 DAMP 以及 Linux 平台上的指标或内存测试。而警报主要使用来自 autoland 的数据，并检查所有平台。此信息的每周审查应该非常快速。
主页https://firefox-dev.tools/performance-dashboard/ 提供指向各个页面的链接，这些页面显示按面板或测试域（例如 DAMP、指标测试等）分组的图表。我建议快速在不同的选项卡中打开每个链接，然后滚动浏览以查看是否有任何明显的回归出现。