如何最佳化Dispatcher快?
本文提供最佳化Dispatcher快取的不同方法的詳細指示。 它進一步說明啟用TTL (「存留時間」或有效期)樣式失效、停用Dispatcher Flush代理程式、重新擷取Dispatcher Flush等等的步驟。
說明 description
環境
Adobe Experience Manager
問題/症狀
本文主要介紹AEM Dispatcher中的最新最佳化以及如何將這些最佳化發揮到極致。 AEM Dispatcher是快取 反向Proxy 專為與Adobe Experience Manager搭配使用而設計的伺服器。 它可以作為現有Web伺服器軟體中的模組來安裝和執行。 在撰寫本文時, 支援Dispatcher模組 在Apache HTTP Server、Microsoft IIS和iPlanet上。
解決方法 resolution
Dispatcher快取如何運作?
在最基本的層面上,AEM Dispatcher是一種反向Proxy,會透過執行快取、快取排清和快取失效來運作。
如需有關 Dispatcher 的更多詳細資訊,請參閱相關連結:
- Dispatcher 運作原理以及如何進行安裝。
- Dispatcher 中可用的設定選項。
- 有關 Dispatcher 運作原理的網路研討會- 請注意,簡報中的某些資訊會根據舊版本的 Dispatcher。
- 有關 Dispatcher 功能、CDN 使用和安全性的 Gems 網路研討會。
- 有關 Dispatcher 中新功能的 Gems 工作階段 (v4.1.9 之後)。
最佳化Dispatcher快取
以下是一些最佳化Dispatcher快取的方法:
-
快取幾乎所有內容 — 這表示快取使用者多次請求的任何內容。
-
快取不同時段的個人化內容 — 如果您的網站有個人化內容,請考慮使用 Apache Sling Dynamic包含 在您的AEM應用程式中,利用Ajax (瀏覽器層級的不同步JavaScript和XML呼叫)、SSI (網頁伺服器層級的伺服器端包含)和ESI (CDN層級的邊緣端包含)來快取不同時段的不同頁面部分。
-
絕不刪除即時 Dispatcher 上的 Dispatcher - 如果 Dispatcher 正在提供即時內容並且您刪除了快取,這將導致大量請求返回 AEM。 因此,絕不應該在即時 Dispatcher 上刪除 Dispatcher 快取。
-
裝填快取 — 刪除Dispatcher快取之前,先從負載平衡器拿掉Dispatcher,刪除快取,然後執行網頁編目程式工具以在Dispatcher上快取檔案,然後再將其放在負載平衡器上。
-
快取錯誤頁面 — 善用 DispatcherPassError 1 (Apache Web Server特定)指示詞,可從Dispatcher快取中提供錯誤頁面,例如404。
-
GZip會壓縮所有檔案型別,預先壓縮的檔案除外 — 在Apache Web Server, mod_deflate 可使用,但請確定 Vary: User-Agent 頁首 未設定。在 Microsoft IIS 中,請使用動態壓縮。
Apache設定範例(僅指定特定內容型別以避免預先壓縮檔案型別):
AddOutputFilterByType DEFLATE文字/html文字/純文字/xml文字/css文字/javascript application/javascript
-
啟用 /serveStaleOnError 在/cache設定中 — 當AEM執行個體出現錯誤時提供舊快取檔案。
-
新增 /gracePeriod 至/cache設定 — 定義在最後一個內容發佈事件(「啟動」)之後仍可從快取中提供過期、自動失效的資源的秒數。 這減少了在大型內容發佈活動 (例如「樹啟動」) 期間返回發佈執行個體的請求數量。
-
將規則新增至 /ignoreUrlParams — 忽略應用程式不需要或不使用的查詢字串引數。 即使存在查詢字串,這也允許快取 URL。
-
快取Cache-Control和Last-Modified回應標題 — 使用 /headers 快取HTTP回應標頭的設定 Cache-Control 和 上次修改時間 (和/或 ETag 標題(若從AEM傳送)。 這有助於在 CDN 和瀏覽器層面簡化和最佳化快取。 快取這些標題使得只有 AEM 可設定標題,網頁伺服器本身則不行。 請注意,執行此操作時,您需要開始從 AEM 應用程式傳送標題。
-
快取內容的時間儘可能拉長 和 減少返回AEM的請求 — 透過在所有排清代理程式上啟用重新擷取排清,將排清請求最佳化。 請參閱以下標題為的章節 重新擷取Dispatcher Flush. 或使用 /enableTTL 並設定 Cache-Control: max-age=… 標題以將檔案快取的時間儘可能拉長。 請參閱下文以了解有關本主題的詳細資訊。
使用TTL
截至Dispatcher版本4.1.11, /enableTTL 1 可在.any檔案組態中設定。 此設定使得Dispatcher採用在HTTP Cache-Control回應標題中設定的快取有效期。 換句話說,Dispatcher 的功能將類似 CDN,當檔案到期時會發生主要形式的快取失效。 實作之後開始傳送 Cache-Control: max-age=… 對於來自AEM的所有回應,您就可以安全地在publish執行個體中停用dispatcher flush代理程式。
在發佈執行個體上停用排清代理程式後,您可能仍希望能夠排清 Dispatcher 快取。 在這種情況下,您可以使用 ACS Commons - Dispatcher Flush UI。 此工具可安裝在作者執行個體上。 它為使用者提供了一個 UI,他們可以在其中執行手動快取排清請求。
I. 啟用 TTL (「存留時間」或有效期) 樣式失效的步驟:
- 修改AEM應用程式中的原始程式碼以傳送 Cache-Control 頁首與 上次修改時間 適用於尚未設定的所有請求。
- 安裝Dispatcher 4.1.11或更新版本。
- 設定 /enableTTL 1 網站的.any陣列設定中。
- 設定 /headers 快取設定 Cache-Control 和 上次修改時間 標頭。
- 重新啟動網頁伺服器。
II. 在發佈執行個體上停用 Dispatcher Flush 代理程式:
Dispatcher現在將使用Cache-Control標頭來控制快取檔案的失效。 既然是這種情況,則不再需要從發佈執行個體中排清 Dispatcher。
- 前往每個發佈執行個體上的/etc/replication/agents.publish.html。
- 前往每個排清代理程式的設定並停用該代理程式。
III. 允許來自作者執行個體的手動 Dispatcher Flush 請求:
由於排清代理程式已停用,您將完全依賴 Cache-Control 標頭,可控制何時在Dispatcher上重新整理內容。 您仍然可以允許使用者核發 Dispatcher 快取的手動排清:
- 在作者執行個體上安裝 ACS Commons - Dispatcher Flush UI。
- 在作者執行個體上設定排清代理程式。
- 在每個代理程式設定中,設定 觸發器 =
>
忽略預設值 選項以啟用。 此選項會使得排清代理程式忽略使用者何時在 AEM UI 中按一下 (取消) 發佈 或者 (取消) 啟動。
重新擷取Dispatcher Flush
為了最佳化Dispatcher Flush請求,所有Dispatcher Flush代理程式都應該啟用稱為重新擷取排清的功能。
若要啟用重新擷取 Dispatcher Flush,請執行以下操作:
-
前往 http://aemhost:port/crx/packmgr/index.jsp 並以管理員身分登入。
-
從此處下載套件。
-
將套件上傳並安裝到封裝管理員。
-
前往 Dispatcher Flush 代理程式設定。例如 /etc/replication/agents.author/flush.html
-
按一下 編輯。
-
設定以下內容
- 序列化類型 = 重新擷取 Dispatcher Flush
- 延伸 =
>
HTTP方法 = POST
-
按一下 儲存。
注意 — 上面安裝的套件只是一個基本範例。 若要自訂和最佳化重新擷取排清,您可以修改它傳送的 URI 清單。 程式碼是開放原始碼,並可以在此處找到。 該程式碼將 URI 清單當成參數新增到請求內文中,告知 Dispatcher 要重新擷取哪些路徑。 您可以根據應用程式要求新增更多路徑,以最佳化網站的快取功能。
重新擷取排清的詳細說明
Dispatcher Flush通常透過刪除檔案來運作:
- 觸控式.stat檔案
- 刪除/content/foo。*
- 刪除/content/foo/_jcr_content
由於在步驟2中刪除檔案,下次使用者請求/content/foo.html或/content/foo.json之類的檔案時,當「重新擷取」檔案時,隨後也將對同一檔案的請求傳送到發佈執行個體,直到已快取檔案。 對於緩慢回應或高流量的頁面 (例如首頁頁面),這可能會導致溢出發佈執行個體層。
若要解決此問題,請啟用 Dispatcher 的一項稱為重新擷取的功能。 此功能允許您傳送 Dispatcher 應主動「重新擷取」並取代而不是刪除的 URI 清單。
如需它如何運作以及如何設定的示範,請參閱 22:41-27:05 (在此簡報錄音中)。