构建缓存性能

要了解缓存可以为您做什么，最直接的方法是衡量非缓存构建和完全缓存构建之间的差异。如果您尝试构建的所有内容都已构建，这将为您提供缓存构建速度的理论限制。衡量这一点的最简单方法是使用本地缓存：

通常，完全缓存的构建应该比构建快得多clean：这是使用构建缓存可以为特定构建节省多少时间的理论限制。通常，您在第一次尝试时无法获得可实现的性能提升，请参阅查找任务输出缓存问题。随着构建逻辑的不断发展和变化，确保缓存有效性不会下降也很重要。构建扫描提供详细的性能细分，显示您的构建使用构建缓存的效率：

当开发人员从版本控制中检查最新版本然后进行构建时，就会发生完全缓存的构建，例如在 IDE 中生成所需的最新源。不过，运行大多数构建的目的是处理一些新的更改。正在构建的软件的结构（有多少个模块，其各部分的独立程度等），以及更改本身的性质（“系统核心的大重构”与“单元测试的小更改”） " 等）强烈影响构建缓存提供的性能增益。由于开发人员倾向于随着时间的推移提交不同类型的更改，因此缓存性能预计会随着每次更改而变化。与任何缓存一样，因此应随着时间的推移来衡量影响。

在团队使用共享缓存后端的设置中，有两个位置值得测量缓存影响：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 中的命中率。点击率的上升可能表明开发人员的使用情况有所改善：

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

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

改善构建和远程缓存之间的网络链接可以显着提高构建缓存性能。如何执行此操作取决于所使用的远程缓存和您的网络环境。

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