快取與效能 caching
元件和GraphQL回應快取 graphql
AEM CIF核心元件已內建對快取個別元件的GraphQL回應的支援。 此功能可用來大幅減少GraphQL後端呼叫的數量。 尤其是對於重複查詢而言，例如擷取導覽元件的類別樹狀結構，或擷取產品搜尋和類別頁面上顯示的所有可用彙總/多面向值，可獲得有效的快取。
對於AEM CIF核心元件，快取是根據元件來設定，因此可以控制是否對每個元件快取GraphQL請求/回應（以及快取多長時間）。 您也可以使用GraphQL使用者端定義OSGi服務的快取行為。
設定 configuration
為指定元件設定後，快取會依照每個快取設定專案的定義，開始儲存GraphQL查詢和回應。 快取的大小和每個專案的快取持續時間會根據專案來定義，例如，根據下列專案而定：
- 目錄資料變更的頻率。
- 元件一律顯示最新可能資料等專案的重要程度。
沒有任何快取失效，因此在設定快取期間時請小心。
為元件設定快取時，快取名稱必須是 proxy 您在專案中定義的元件。
在使用者端傳送GraphQL請求之前，會檢查是否要 確切 已快取相同的GraphQL請求，並且可能會傳回快取的回應。 為了比對，GraphQL請求 必須 完全相符。 也就是查詢、作業名稱（如果有的話）、變數（如果有的話） 必須 都等於快取的要求。 而且，所有可能設定的自訂HTTP標頭 必須 也是相同的。 例如Adobe Commerce Store 頁首 必須 相符。
範例 examples
Adobe建議您為search服務設定一些快取，以便擷取product search和category頁面上顯示的所有可用彙總/多面向值。 例如，這些值通常只有在將新屬性新增至產品時才會變更。 因此，如果產品屬性集不經常變更，則此快取專案的持續時間可能會「很大」。 雖然此專案是專案專用的，但Adobe建議在專案開發階段使用幾分鐘的值，並在穩定生產系統上使用幾小時。
此設定通常會使用下列快取專案進行設定：
com.adobe.cq.commerce.core.search.services.SearchFilterService:true:10:3600
另一個建議使用GraphQl快取功能的範例情況是導覽元件。 原因是它會在所有頁面上傳送相同的GraphQL查詢。 在這種情況下，快取專案通常會設為：
venia/components/structure/navigation:true:10:600
考量到 Venia參考存放區 已使用。 請注意元件Proxy名稱的使用 venia/components/structure/navigation、和 not CIF導覽元件的名稱(core/cif/components/structure/navigation/v1/navigation)。
其他元件的快取應根據專案來定義，通常與在Dispatcher層級設定的快取協調。 請記住，這些快取沒有任何作用中的失效機制，因此應謹慎設定快取持續時間。 沒有任何「一刀切」的值會符合所有可能的專案和使用案例。 請務必在專案層級定義最符合專案需求的快取策略。
Dispatcher快取 dispatcher
在中快取AEM頁面或片段 AEM傳送器 是任何AEM專案的最佳實務。 通常，它仰賴失效技術，以確保在AEM中變更的任何內容在Dispatcher中正確更新。 此功能是AEM Dispatcher快取策略的核心。
除了純AEM管理的內容CIF之外，頁面通常可以顯示透過GraphQL從Adobe Commerce動態擷取的商務資料。 雖然頁面結構本身可能不會變更，但商務內容可能會變更。 例如，如果產品資料（例如名稱和價格）在Adobe Commerce中變更。
為了確保CIF頁面在AEM Dispatcher中的快取時間有限，Adobe建議使用 基於時間的快取失效 （也稱為TTL型快取）在AEM Dispatcher中快取CIF頁面時。 此功能可在AEM中設定，使用額外的 ACS AEM Commons 封裝。
透過TTL型快取，開發人員通常會為選取的AEM頁面定義一或多個快取持續時間。 此持續時間可確保AEM Dispatcher中僅快取CIF頁面，直到設定的持續時間為止，並且經常更新內容。
product， productlist、和 searchresults 載入頁面時，元件通常會一律在使用者端瀏覽器請求中重新擷取產品價格。 這麼做可確保頁面載入時總是會擷取重要的動態內容。