使用任何构建缓存的唯一原因是为了让构建更快。但是,使用缓存时能快多少呢?衡量其影响既重要又复杂,因为缓存性能由许多因素决定。衡量缓存的影响可以验证开始使用缓存所需的额外工作(工作量、基础设施)。这些衡量结果以后可以作为未来改进的基线,并用于发现退步的迹象。

适当的构建配置和维护可以大大提高缓存性能。

完全缓存的构建

了解缓存能为您做什么的最直接方法是测量非缓存构建和_完全缓存_构建之间的差异。这将为您提供使用缓存时构建速度的理论极限,前提是您尝试构建的所有内容都已构建。最简单的测量方法是使用本地缓存

  1. 清除缓存目录以避免之前构建的任何命中(rm -rf $GRADLE_USER_HOME/caches/build-cache-*

  2. 运行构建(例如 ./gradlew --build-cache clean assemble),以便所有可缓存任务的结果都存储在缓存中。

  3. 再次运行构建(例如 ./gradlew --build-cache clean assemble);根据您的构建,您应该会看到许多任务从缓存中检索。

  4. 比较两次构建的执行时间

即使在两次构建中的第一次构建中,您也可能会遇到一些缓存任务,而此时不应该有任何先前缓存的结果可用。如果您的构建中有任务配置为从相同的输入生成相同的结果,则可能会发生这种情况;在这种情况下,一旦其中一个任务完成,Gradle 将简单地重用其输出用于其余任务。

通常,您的_完全缓存_构建应该比 `clean` 构建快得多:这是使用构建缓存可以在您的特定构建中节省多少时间的理论极限。通常,您第一次尝试无法获得可实现的性能提升,请参阅查找任务输出缓存问题。随着您的构建逻辑不断演进和变化,确保缓存效率没有退步也很重要。构建扫描提供详细的性能分解,显示您的构建如何有效地使用构建缓存

performance task execution

完全缓存的构建发生在开发人员从版本控制中检出最新版本然后进行构建的情况下,例如为了在他们的 IDE 中生成他们需要的最新源代码。然而,运行大多数构建的目的是处理一些新的更改。所构建软件的结构(有多少模块,其部件的独立性如何等)以及更改本身的性质(“系统核心的大型重构”与“对单元测试的小改动”等)强烈影响构建缓存带来的性能提升。由于开发人员会随着时间的推移提交不同类型的更改,因此缓存性能预计会随着每次更改而变化。与任何缓存一样,其影响因此应随时间进行衡量。

在团队使用共享缓存后端的设置中,有两个值得衡量缓存影响的位置:CI 和开发人员机器。

缓存对 CI 构建的影响

了解缓存对 CI 影响的最佳方法是设置启用和禁用缓存的相同构建,并随时间比较结果。如果您想为单个 Gradle 构建步骤启用缓存,则可以使用 CI 系统的内置统计工具轻松比较结果。

测量复杂的管道可能需要更多的工作或外部工具来收集和处理测量结果。区分缓存没有影响的管道部分非常重要,例如,构建在 CI 系统队列中等待的时间,或从版本控制中检出源代码所花费的时间。

使用 Develocity 时,您可以使用导出 API 访问所需数据并运行分析。与从 CI 服务器获得的数据相比,Develocity 提供了更丰富的数据。例如,您可以深入了解单个任务的执行情况、从缓存中检索了多少任务、从缓存下载所需的时间、用于计算缓存键的属性等等。当使用您的 CI 服务器内置功能时,如果您将 Teamcity 用于 CI 构建,您可以使用统计图表。大多数情况下,您最终会通过相应的 REST API 从您的 CI 服务器提取数据(请参阅Jenkins 远程访问 APITeamcity REST API)。

通常,达到一定规模的 CI 构建会包含并行部分以利用多个代理。通过并行管道,您可以衡量一组更改从推送到版本控制到构建、验证和部署所花费的实际时间。在这种情况下,构建缓存的效果可以通过缩短开发人员等待 CI 反馈的时间来衡量。

您还可以测量构建代理构建变更集所花费的累计时间,这将让您了解 CI 基础设施需要付出的工作量。缓存在此处的效果是减少 CI 资源的花费,因为您不需要那么多 CI 代理来维护相同数量的已构建更改。

如果您想查看 Gradle 构建本身的测量结果,您可以查看博客文章 “引入构建缓存”

测量开发者构建

Gradle 的构建缓存对于降低 CI 基础设施成本和反馈时间非常有用,但通常在开发人员可以在其本地构建中重用缓存结果时,其影响最大。由于多种原因,这也最难量化

  • 开发者运行不同的构建

  • 开发者可能有不同的硬件,或者有不同的设置

  • 开发者在他们的机器上运行各种其他东西,这可能会减慢它们的速度

使用 Develocity 时,您也可以使用导出 API 提取有关开发者构建的数据。然后,您可以创建关于每个开发者或构建缓存了多少任务的统计信息。您甚至可以比较执行任务与从缓存加载任务所需的时间,然后估算每个开发者节省的时间。

当使用 Develocity 构建缓存后端时,您应该密切关注管理 UI 中的命中率。命中率的提高可能表明开发人员的使用情况更好

build cache hit rate

在构建扫描中分析性能

构建扫描通过“性能”页面的_“构建缓存”_部分,提供构建的所有缓存操作摘要。

build cache performance

此页面详细说明了哪些任务可以通过缓存命中避免,哪些未命中。它还分别指出了本地和远程缓存的命中和未命中情况。对于远程缓存操作,给出了将工件传输到缓存和从缓存传输所需的时间,以及传输速率。这对于评估网络链路质量对性能的影响尤为重要,因为传输时间会影响构建时间。

远程缓存性能

改善构建与远程缓存之间的网络链接可以显著提高构建缓存性能。如何做到这一点取决于正在使用的远程缓存和您的网络环境。

Develocity 提供的多节点远程构建缓存是一种快速高效的专用远程构建缓存。特别是,如果您的开发团队地理上分散,其复制功能可以通过允许开发人员使用他们有良好网络连接的缓存来显著提高性能。有关更多信息,请参阅 Develocity 管理手册的“构建缓存复制”部分