在 Discourse 核心、插件或主题中处理客户端工作时，考虑性能影响至关重要。Google 的 “Tachometer” 项目提供了一个统计上严谨的基准测试工具，我们可以使用它来确切地衡量变更带来的影响。
本质上，该工具会获取一个 URL 列表，并以“轮询”（round-robin）方式加载它们。对于每次页面加载，它会采集一些性能指标。在数百次或数千次迭代后，它会生成一个对比表。
这种“轮询”方法的美妙之处在于，它有助于减少外部因素对测量结果的影响。
步骤 1：添加 performance.measure()
具体方法取决于你要测试的内容。但根本原则是：你需要引入一个 performance.measure() 值，以便 Tachometer 读取。
如果你想测量 Discourse 启动并渲染所需的时间，可以使用内置的 “discourse-init-to-paint” 测量值。对于其他任何内容，你可以引入自己的 performance.measure 并使用它。
你可以使用浏览器开发者工具中的性能选项卡来检查其是否正常工作：
如果你试图测量需要用户交互的活动（例如打开菜单），你可以通过在初始化器中添加类似以下内容来实现，该代码会在页面加载 1 秒后点击按钮：
setTimeout(() => document.querySelector(".my-button").click(), 1000);
步骤 2：确定用于测试的 URL
首先，确保你在生产模式下构建 Ember 资源。这可以通过使用 EMBER_ENV=production 启动服务器来实现。
要获取两个不同的 URL，主要有两种方法：
如果你的变更足够小，可以轻松地进行功能标志（feature-flag）控制，那么你可以添加逻辑，根据 URL 查询参数 来切换它。然后你的两个 URL 可以是
http://localhost:3000?flag=before
http://localhost:3000?flag=after
如果变更太大而无法这样做，你可以将 Discourse 克隆到第二个目录，并启动 第二个 rails 实例。
EMBER_ENV=production UNICORN_PORT=3001 bin/dev
然后你的两个 URL 将是
http://localhost:3000
http://localhost:3001
如果你采用这种方法，请确保应用程序的两个副本都包含你在本指南步骤 1 中引入的性能遥测功能。
步骤 3：配置 Tachometer
这是我的 bench.json 文件，它将针对每个目标采集 300 个样本：
{
"timeout": 5,
"sampleSize": 300,
"benchmarks": [
{
"measurement": {
"mode": "performance",
"entryName": "discourse-init-to-paint"
},
"expand": [
{
"url": "http://localhost:3000",
"name": "before"
},
{
"url": "http://localhost:3001",
"name": "after"
}
]
}
]
}
步骤 4：运行基准测试
为了减少噪声，请停止工作站上任何无关的活动，然后使用类似以下命令启动基准测试：
npx tachometer@latest --config ./bench.json
完成后，你应该能看到变更前后的性能对比。
注意事项
与任何此类实验一样，值得考虑其局限性。例如：
-
你的开发工作站上的性能差异可能不会直接映射到其他浏览器/设备上
-
通过 Ember-CLI 代理启动 Discourse 的启动过程与生产环境中的过程并不完全相同。在进行结构性变更（例如框架更新）时，这可能很重要
-
性能通常会根据应用程序状态（例如正在渲染的主题数量）而变化，因此你的结果可能无法在其他环境中完全复现
本文档受版本控制 - 在 github 上建议更改。