使用任何构建缓存的唯一原因是使构建更快。但是，使用缓存时可以快多少？测量影响既重要又复杂，因为缓存性能受许多因素决定。执行缓存影响的测量可以验证开始使用缓存所需的额外工作（工作、基础设施）。这些测量可以作为未来改进的基线，并用于观察回归迹象。

正确配置和维护构建可以极大地提高缓存性能。

完全缓存的构建

了解缓存对您有什么帮助的最直接方法是测量非缓存构建和完全缓存构建之间的差异。这将为您提供使用缓存时构建速度的理论极限，如果您要构建的所有内容都已构建。最简单的测量方法是使用本地缓存

  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 远程访问 API 和 Teamcity REST API）。

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

您还可以衡量构建代理用于构建更改集的累计时间，这将让您了解 CI 基础设施需要投入多少工作量。缓存的效果在这里是减少了 CI 资源的支出，因为您不需要那么多 CI 代理来维护相同数量的构建更改。

如果您想查看 Gradle 构建本身的度量，可以查看博客文章 "介绍构建缓存"。

衡量开发人员构建

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

  • 开发人员运行不同的构建

  • 开发人员可能拥有不同的硬件，或者拥有不同的设置

  • 开发人员在他们的机器上运行各种其他程序，这些程序可能会减慢他们的速度

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

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

build cache hit rate

分析构建扫描中的性能

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

build cache performance

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

远程缓存性能

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

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