使用任何构建缓存的唯一理由是使构建更快。但是，当使用缓存时，您可以提高多少速度？衡量影响既重要又复杂，因为缓存性能由许多因素决定。执行缓存影响的衡量可以验证启动使用缓存所需的额外工作（工作、基础设施）。这些测量结果可以在以后用作未来改进的基线，并用于观察回归迹象。
| 正确配置和维护构建可以大大提高缓存性能。 |
完全缓存的构建
了解缓存可以为您做什么的最直接方法是衡量非缓存构建和完全缓存构建之间的差异。如果您尝试构建的所有内容都已构建，这将使您了解使用缓存的构建可以达到的理论极限速度。衡量此速度的最简单方法是使用本地缓存
-
清除缓存目录以避免来自先前构建的任何命中（
rm -rf $GRADLE_USER_HOME/caches/build-cache-*） -
运行构建（例如
./gradlew --build-cache clean assemble），以便将来自可缓存任务的所有结果存储在缓存中。 -
再次运行构建（例如
./gradlew --build-cache clean assemble）；根据您的构建，您应该看到许多任务是从缓存中检索的。 -
比较两个构建的执行时间
| 即使在两个构建中的第一个构建中，您也可能会遇到一些缓存的任务，其中不应有先前缓存的结果可用。如果您在构建中配置了任务以从相同的输入产生相同的结果，则可能会发生这种情况；在这种情况下，一旦其中一项任务完成，Gradle 将简单地将其输出重用于其余任务。 |
通常，您的完全缓存构建应该比 clean 构建快得多：这是使用构建缓存可以在您的特定构建上节省多少时间的理论极限。您通常不会在第一次尝试时获得可实现的性能提升，请参阅查找任务输出缓存的问题。随着您的构建逻辑不断发展和变化，确保缓存有效性不会降低也很重要。构建扫描提供详细的性能分解，向您展示您的构建使用构建缓存的效率
当开发人员从版本控制中检出最新版本，然后进行构建（例如，生成 IDE 中需要的最新源代码）时，会发生完全缓存的构建。但是，运行大多数构建的目的是处理一些新的更改。正在构建的软件的结构（有多少模块，其各个部分有多独立等）以及更改本身的性质（“系统核心中的大型重构”与“对单元测试的小更改”等）强烈影响构建缓存带来的性能提升。由于开发人员倾向于随着时间的推移提交不同类型的更改，因此缓存性能预计会因每次更改而异。与任何缓存一样，因此应随着时间的推移衡量其影响。
在团队使用共享缓存后端的设置中，有两个位置值得衡量缓存影响：在 CI 和开发者机器上。
缓存对 CI 构建的影响
了解缓存对 CI 影响的最佳方法是设置启用和禁用缓存的相同构建，并随着时间的推移比较结果。如果您有一个要启用缓存的 Gradle 构建步骤，则可以使用 CI 系统的内置统计工具轻松比较结果。
衡量复杂的流水线可能需要更多的工作或外部工具来收集和处理测量结果。区分流水线中缓存没有影响的那些部分很重要，例如，构建在 CI 系统的队列中等待的时间，或者从版本控制中检出源代码所花费的时间。
当使用 Develocity 时，您可以使用 Export API 访问必要的数据并运行您的分析。与从 CI 服务器获得的数据相比，Develocity 提供了更丰富的数据。例如，您可以深入了解单个任务的执行情况、从缓存中检索了多少任务、从缓存下载所需的时间、用于计算缓存键的属性等等。当使用 CI 服务器的内置功能时，如果您使用 Teamcity 进行 CI 构建，则可以使用统计图表。大多数时候，您最终将通过相应的 REST API 从 CI 服务器提取数据（请参阅Jenkins 远程访问 API 和 Teamcity REST API）。
通常，超过一定大小的 CI 构建包括并行部分，以利用多个代理。使用并行流水线，您可以衡量一组更改从推送到版本控制到构建、验证和部署所花费的挂钟时间。在这种情况下，构建缓存的效果可以用开发人员必须等待来自 CI 反馈的时间减少来衡量。
您还可以衡量构建代理花费在构建变更集上的累积时间，这将使您了解 CI 基础设施必须付出的工作量。缓存在这里的效果是减少了在 CI 资源上的花费，因为您不需要那么多 CI 代理来维护相同数量的已构建更改。
如果您想查看 Gradle 构建本身的衡量标准，您可以查看博客文章“Introducing the build cache”。
衡量开发者构建
Gradle 的构建缓存对于降低 CI 基础设施成本和反馈时间非常有用，但当开发人员可以在本地构建中重用缓存结果时，它通常具有最大的影响。由于以下几个原因，这也最难量化
-
开发者运行不同的构建
-
开发者可能拥有不同的硬件或不同的设置
-
开发者在其机器上运行各种其他可能减慢速度的事情
当使用 Develocity 时，您也可以使用 Export API 提取有关开发者构建的数据。然后，您可以创建关于每个开发者或构建缓存了多少任务的统计信息。您甚至可以比较执行任务所需的时间与从缓存加载任务所需的时间，然后估算每个开发者节省的时间。
当使用 Develocity 构建缓存后端时，您应密切关注管理 UI 中的命中率。命中率的上升可能表明开发者更好地使用了缓存
在构建扫描中分析性能
构建扫描通过“性能”页面的“构建缓存”部分提供构建的所有缓存操作的摘要。
此页面详细说明了哪些任务能够通过缓存命中避免，以及哪些任务未命中。它还分别指示本地和远程缓存的命中和未命中。对于远程缓存操作，给出了将构件传输到缓存和从缓存传输构件所花费的时间，以及传输速率。这对于评估网络链路质量对性能的影响尤为重要，因为传输时间会影响构建时间。
远程缓存性能
改善构建和远程缓存之间的网络链路可以显着提高构建缓存性能。如何做到这一点取决于正在使用的远程缓存和您的网络环境。
Develocity 提供的多节点远程构建缓存是一种快速高效、专门构建的远程构建缓存。特别是，如果您的开发团队在地理上是分散的，其复制功能可以通过允许开发人员使用与其网络链路良好的缓存来显着提高性能。有关更多信息，请参阅 Develocity 管理手册的“构建缓存复制”部分。