建立快取效能

最直接的方法來了解快取可以為您做什麼，就是測量非快取建置和完全快取建置之間的差異。這將為您提供使用快取的建置可以多快的理論極限，如果您要建置的所有內容都已建置完畢。測量此項目的最簡單方法是使用本機快取

通常，您的完全快取建置應該會比 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 時，您可以使用 Export API 來擷取有關開發人員建置的資料。然後，您可以建立統計資料，了解每個開發人員或建置快取了多少個工作。您甚至可以比較執行工作與從快取載入工作所花費的時間，然後估計每個開發人員節省的時間。

使用 Develocity 建置快取後端 時，您應該密切注意管理員 UI 中的命中率。命中率在那裡上升可能表示開發人員有更好的使用情況

建置掃描提供建置所有快取操作的摘要，透過「效能」頁面的「建置快取」區段。

此頁面詳細說明哪些工作能夠透過快取命中而避免，以及哪些工作錯失。它也個別指出本機和遠端快取的命中和錯失。對於遠端快取操作，會提供將人工製品傳輸至快取和從快取傳輸人工製品所花費的時間，以及傳輸速率。這對於評估網路連結品質對效能的影響特別重要，因為傳輸時間會影響建置時間。

改善建置和遠端快取之間的網路連結可以大幅改善建置快取效能。如何執行此操作取決於所使用的遠端快取和您的網路環境。

Develocity 提供的多節點遠端建置快取是一種快速且有效率的專門建置遠端快取。特別是，如果您的開發團隊在地理位置上分散，其複製功能可以透過允許開發人員使用具有良好網路連結的快取來大幅改善效能。請參閱 Develocity 管理員手冊的「建置快取複製」區段 以取得更多資訊。