正在加载

CI 指标

除了运行我们的测试之外，CI 还会收集有关 Kibana 构建的指标。这些指标被发送到一个外部服务，以跟踪随时间的变化，并为 PR 作者提供有关其更改影响的见解。

这些指标帮助贡献者了解他们如何影响 Kibana 创建的包的大小，并确保 Kibana 尽可能快地加载。

page load bundle size

为每个包/插件生成的入口文件的大小。此文件始终在每个页面加载时加载，因此应尽可能小。要减小此指标，您可以将每个页面加载不需要的任何代码放在 async import() 后面。

与其他插件静态共享的代码将计入该插件的 page load bundle size。这包括来自 public/index.ts 文件的导出，以及 extraPublicDirs 清单属性引用的任何文件。

async chunks size
为每个 async import() 语句导入的文件创建一个“异步块”。此指标跟踪这些块的总大小（以字节为单位），按插件/包 ID 分解。您可以将其视为用户访问包中的所有组件/应用程序时必须下载的代码量。
miscellaneous assets size
“杂项资产”是指任何不是异步块或入口块的东西，通常是图像。此指标跟踪这些资产的总大小（以字节为单位），按插件/包 ID 分解。
@kbn/optimizer bundle module count
每个包/插件中包含的单独模块的数量。这是我们拥有的关于特定包需要多长时间才能被 @kbn/optimizer 构建的最佳指标，因此我们报告它以帮助人们知道他们何时导入了一个可能包含大量子模块的模块。

Kibana 可分发文件的大小是一个重要的指标，因为它不仅会增加下载时间，还会影响下载后解压存档所需的时间。

有一些指标我们不会在 PR 中报告，因为 gzip 压缩即使在提供相同输入时也会产生不同的文件大小，因此即使 PR 作者没有进行任何相关更改，此指标也会定期显示更改。

所有指标都从为 linux 平台生成的 tar.gz 存档中收集。

distributable file count
默认可分发文件中包含的文件数。
distributable size
默认可分发文件的大小（以字节为单位）。（不在 PR 中报告）

Elasticsearch 默认将索引中的字段数限制为 1000，我们希望避免提高该限制。

Saved Objects .kibana field count
按已保存对象类型分解的已保存对象字段的数量。

您可以使用 @kbn/dev-utils 包提供的 CiStatsReporter 类来报告新指标。此类在 CI 上自动配置，并且其方法在 CI 之外运行时不执行任何操作。有关更多详细信息，请查看 CiStatsReporter readme。

为了防止页面加载包意外增长过大，我们限制了每个插件的 page load asset size 指标。当 PR 将此指标增加到超过 limits.yml 中为该插件定义的限制时，将设置失败的提交状态，PR 作者需要决定如何在合并 PR 之前解决此问题。

在大多数情况下，限制应该足够高，PR 不应该触发超限，但是当它们确实发生时，通过尝试以下操作来确保清楚导致超限的原因

  1. 使用 --profile 标志在本地运行优化器，为可以使用许多不同在线工具检查的包生成 webpack stats.json 文件。重点关注名为 {{pluginId}}.plugin.js 的块；*.chunk.js 块组成了 async chunks size 指标，目前没有限制，并且是我们 减小页面加载块大小 的主要方法。

    node scripts/build_kibana_platform_plugins --focus {pluginid} --profile
# builds and creates {pluginDir}target/public/stats.json files for {pluginId} and any plugin it depends on

  2. 您可能还想为 PR 的上游分支创建统计信息，然后在 Webpack 可视化工具中并排比较它们，以找出大小差异的位置（使用两个浏览器选项卡）。

  3. 对于相对较小的更改，您可以通过将来自两个不同分支的 stats.json 文件放入 Beyond Compare 中来更好地理解问题

  4. 如果 Beyond Compare 中的更改数量过多，您可以使用 jq 将 stats.json 文件减少到仅包含已排序的模块 ID 列表

    jq -r .modules[].id {pluginDir}/target/public/stats.json | sort - > moduleids.txt

    为您的分支和 master 分别生成一个 moduleids.txt 文件，然后将它们放入 Beyond Compare 中，以获得非常具体的关于新增内容的视图。

  5. 作为最后的手段，您可能想尝试直接比较包源代码。通常最好使用生产源代码，这样您就可以检查 CI 看到的实际字节变化。构建包的可分发版本后，通过 prettier 运行它，然后将其与来自上游的块一起放入 Beyond Compare 中

    node scripts/build_kibana_platform_plugins --focus {pluginId} --dist
npm install -g prettier
prettier -w {pluginDir}/target/public/{pluginId}.plugin.js
# repeat these steps for upstream and then compare the two {pluginId}.plugin.js files in Beyond Compare

  6. 如果所有方法都失败，请联系 Operations 寻求帮助。

一旦您确定了添加到构建中的文件，您可能只需要按照 插件性能 中所述，将它们放在异步导入后面。

如果包大小没有被任何明显的东西膨胀，但仍然大于限制，您可以在您的 PR 中提高限制。通过手动编辑 limits.yml 文件 或运行以下命令将限制更新为当前大小 + 15kb 来完成此操作

node scripts/build_kibana_platform_plugins --focus {pluginId} --update-limits

此命令必须在可分发模式下运行优化器，因此它会花费更长的时间，并且会为您的机器上的每个 CPU 产生一个工作线程。

对 limits.yml 文件 的更改将触发 Operations 团队的审查，他们将尝试验证大小增加是否合理。如果您可以分享从上述步骤中获得的发现，这将非常有帮助！

当您试图跟踪可以改进包大小的更改时，请尝试在本地运行以下命令

node scripts/build_kibana_platform_plugins --dist --watch --focus {pluginId}

这将为您的插件及其依赖的插件构建前端包。每当您进行更改时，包都会被重建，您可以在插件中的 target/public/metrics.json 文件中检查该构建的指标。此文件将在您保存对源代码的更改时更新，并且应该有助于确定您的更改是否充分降低了 page load asset size。

如果您只想运行一次构建，您可以运行

node scripts/build_kibana_platform_plugins --validate-limits --focus {pluginId}

此命令需要应用生产优化才能获得正确的大小，这意味着优化器将花费更长的时间来运行，并且在大多数开发人员机器上，将消耗机器的所有资源 20 分钟或更长时间。如果您想在运行此命令时进行多任务处理，您可能需要使用 --max-workers 标志限制工作线程的数量。

© . All rights reserved.