Dispatcher 版本與 AEM 無關。如果您依循了內嵌到舊版 AEM 文件中的 Dispatcher 文件的連結,您可能會被重新導向至本頁。
Dispatcher 是 Adobe Experience Manager 的快取及負載平衡工具,搭配企業級網頁伺服器使用。
部署 Dispatcher 的程序與所選的網頁伺服器和作業系統平台無關:
若要更了解 Dispatcher 如何搭配 AEM 使用:
視需要使用下列資訊:
Dispatcher 最常見的用法是快取來自 AEM Publish 執行個體的回應,以提高您對外發佈網站的回應速度與安全性。大多數的討論均強調此用途。
但是,Dispatcher 也可用來提高您編寫執行個體的回應速度,尤其是如果您有大量使用者編輯和更新您的網站時特別實用。如需此情況特有的詳細資訊,請參閱下方的搭配撰寫伺服器使用 Dispatcher。
網路出版的基本方式有兩種:
Dispatcher 有助於實現快速和動態的環境。這可當成是靜態 HTML 伺服器 (例如 Apache) 的一部分,但其目的是:
這表示:
靜態內容在靜態網頁伺服器上以同樣的速度輕鬆處理。 此外,您還可以使用適用於靜態網頁伺服器的管理和安全性工具。
動態內容會視需要產生,除非絕對需要,否則並不會讓系統變慢。
Dispatcher 包含的機制可根據動態網站上的內容來產生和更新靜態的 HTML。您可以詳細指定要將哪些文件儲存為靜態檔案,哪些一律動態產生。
本節說明此程序背後的原理。
靜態網頁伺服器 (例如 Apache 或 IIS) 會為網站的訪客提供靜態 HTML 檔案。靜態頁面只需建立一次,之後會針對每項請求傳送相同的內容。
此過程非常簡單且有效率。 如果訪客要求檔案 (例如 HTML 頁面),則通常會直接從記憶體擷取檔案,不然頂多是從本機磁碟讀取檔案。 靜態網頁伺服器已上市相當長一段時間,因此已經有多種管理和安全管理工具,並且與網路基礎架構適當整合。
如果您使用的是 CMS (內容管理伺服器),例如 AEM,進階版面引擎會處理訪客的請求。 引擎會從存放庫讀取內容,並結合樣式、格式和存取權限,將內容轉換為符合訪客需求和權限的文件。
此工作流程可讓您建立更豐富的動態內容,進而提高網站的彈性和功能。 不過,版面引擎比靜態伺服器需要更強大的處理能力,因此,如果有許多訪客使用系統,此設定可能會讓速度緩慢。
快取目錄針對快取,Dispatcher 模組會使用網頁伺服器的功能提供靜態內容。Dispatcher 會將快取的文件置於網頁伺服器的主目錄。
當缺少 HTTP 標頭快取的設定時,Dispatcher 只會儲存頁面的 HTML 程式碼,不會儲存 HTTP 標頭。如果您的網站使用不同的編碼,這種情況可能會發生問題,因為這些頁面可能會遺失。 如要啟用 HTTP 標頭快取,請參閱設定 Dispatcher 快取。
在網路連接儲存裝置 (NAS) 上尋找網頁伺服器的主目錄會導致效能降低。此外,當 NAS 上的主目錄在多部網頁伺服器之間共用時,執行複製操作時可能會發生間歇鎖定。
Dispatcher 將快取的文件以與請求的 URL 相同的結構儲存。
檔案名稱的長度可能有作業系統層級的限制。 也就是說,如果您有一個包含多個選擇器的 URL。
Dispatcher 有兩種主要方法,用於在對網站進行更改時更新快取內容。
每次內容更新會變更一或多個 AEM 文件。AEM 會傳送整合請求給 Dispatcher,Dispatcher 會隨之更新快取:
請注意下列幾點:
自動失效功能會自動讓部分的快取失效,而不會實際刪除任何檔案。在每次內容更新時,都會接觸到所謂的 statfile,因此其時間戳記都會顯示最後一次的內容更新。
Dispatcher 有一個檔案清單,這些檔案會自動失效。請求該清單中的文件時,Dispatcher 會將快取文件的日期與 statfile 的時間戳相比較:
同樣請您注意下列幾點:
您可以定義 Dispatcher 會在設定檔案中快取哪些文件。 Dispatcher 會根據可快取文件清單來檢查請求。如果文件不在此清單中,Dispatcher 會請求 AEM 執行個體的文件。
在下列情況下,Dispatcher 一律會直接從 AEM 執行個體要求文件:
?
」。 這種情況通常表示這是一個不需要快取的動態頁面,例如搜尋結果。Dispatcher 可快取 GET 或 HEAD (用於 HTTP 標頭) 方法。如需有關回應標頭快取的其他資訊,請參閱快取 HTTP 回應標頭一節。
Dispatcher 會將快取的檔案儲存在網頁伺服器上,就像是靜態網站的一部分一樣。如果使用者請求可快取文件,Dispatcher 會將檢查該文件是否存在於 Web 伺服器的檔案系統中:
為了要瞭解文件是否為最新版本,Dispatcher 會執行下列兩個步驟:
未自動失效的文件會保留在快取中,直到實際上遭到刪除為止。 例如透過網站上的內容更新。
「負載平衡」是將網站的運算負載分配至數個 AEM 執行個體的作法。
其優點如下:
提高處理能力
在實務中,提高處理能力表示 Dispatcher 會將文件請求在數個 AEM 執行個體之間分享。 由於每個執行個體現在要處理的文件數量較少,因此您的回應時間就會變快。Dispatcher 會保留每個文件類別的內部統計資料,以便能夠估計負載並有效率地分配查詢。
增加防故障的涵蓋範圍
如果 Dispatcher 沒有收到來自執行個體的回應,就會自動將請求轉送給其他執行個體之一。 如果某個執行個體無法使用,唯一的影響是網站速度變慢,與失去的運算能力成正比。 但是所有服務都會繼續。
您也可以從同一部靜態網頁伺服器上管理不同的網站。
雖然負載平衡可以有效率地分散負載,但快取可有助於降低負載。因此,在設定負載平衡之前,請嘗試最佳化快取並降低整體的負載。良好的快取可以提高負載平衡器的效能,或不需要進行負載平衡。
雖然單一 Dispatcher 通常讓可用的 Publish 執行個體的容量達到飽和,但對於某些罕見的應用程式而言,另外平衡兩個 Dispatcher 執行個體的負載是有必要的。 設定多個 Dispatcher 前必須詳加考量,因為額外的 Dispatcher 可能增加可用的 Publish 執行個體的負載,並且很容易就可能會降低大多數應用程式的效能。
Dispatcher 會保留內部統計資料,瞭解 AEM 每個執行個體處理檔案的速度。Dispatcher 會根據此資料,估計在回應請求時哪個執行個體可提供最快的回應時間,藉此來保留該執行個體所需的運算時間。
不同類型的請求可能會有不同的平均完成時間,因此 Dispatcher 可讓您指定文件類別。 然後在運算時間估計值時考慮這些類別。 例如,您可以區分 HTML 頁面和影像,因為此二者的一般回應時間會有所不同。
如果您使用複雜的搜尋功能,則可為搜尋查詢建立類別。 此方法可幫助 Dispatcher 將搜索查詢傳送給回應速度最快的執行個體。 它也有助於避免速度較慢的執行個體收到數個「昂貴」的搜尋查詢時停頓下來,而其他執行個體反而收到「較便宜」的請求。
黏著連線可確保同一個使用者的文件都是在 AEM 的同一個執行個體上撰寫。如果您使用個人化頁面和工作階段資料,這一點會很重要。 資料會儲存在同一執行個體上,因此來自相同使用者的後續請求都必須傳回給該執行個體,否則資料會遺失。
由於黏著連線會限制 Dispatcher 最佳化請求的功能,因此您應該視需要來使用。您可以指定包含「黏著」文件的檔案夾,如此可確保該檔案夾中的所有文件都是針對每位使用者在相同執行個體上所撰寫。
針對使用黏著連線的大部分頁面,您必須關閉快取功能,否則無論工作階段內容為何,對所有使用者而言頁面看起來都一樣。
對於少數應用程式而言,可以同時使用黏著連線和快取;例如如果顯示將資料寫入工作階段的表單。
您可以透過複雜的設定來使用多個 Dispatcher。例如您可以使用:
在這種情況下,請確定每個請求只通過一個 Dispatcher。Dispatcher 不會處理來自其他 Dispatcher 的請求。因此,請確定兩個 Dispatcher 都直接存取 AEM 網站。
內容傳遞網路 (CDN) (例如 Akamai Edge Delivery 或 Amazon Cloud Front) 會從接近使用者的位置傳遞內容。藉此可
CDN 為 HTTP 基礎架構元件,其運作方式與 Dispatcher 類似。當 CDN 節點收到請求時,會盡可能從其快取中提供請求 (該資源可在快取中取得並且有效)。 否則,會前往下一個最近的伺服器,為進一步的請求擷取資源並加以快取 (如適用)。
「下一個最近的伺服器」要取決於您的特定設定。例如在 Akamai 設定中,請求可採取下列路徑:
通常,Dispatcher 是下一個最近的伺服器,可從快取中提供檔案,並影響傳回至 CDN 伺服器的回應標頭。
有數種方法可控制 CDN 從 Dispatcher 重新擷取資源前,快取資源多久的時間。
明確設定
視 MIME 類型、副檔名、請求類型等,設定 CDN 快取保存特定資源的時長。
到期日和快取控制標頭
如果是由上游伺服器傳送,大部分的 CDN 都會遵守 Expires:
和 Cache-Control:
HTTP 標頭。 例如,可藉由使用 mod_expires Apache 模組來達成此方法。
手動失效
CDN 可透過 Web 介面從快取中移除資源。
API 型失效
大部分的 CDN 也提供 REST 和/或 SOAP API,可從快取中移除資源。
在一般的 AEM 設定中,只要按副檔名、路徑或兩者進行設定 (可透過上述第 1 和第 2 點達成),即可為經常使用的資源 (例如設計影像和用戶端程式庫) 設定合理的快取期限。 部署新版本時,通常需要手動失效。
如果將此方法用於快取受管理的內容,則表示只有在已設定的快取期限到期,並且已再次從 Dispatcher 中擷取文件後,使用者才能看到內容變更。
為了達到更精細的控制,API 型的失效可讓您在 Dispatcher 快取失效時將 CDN 的快取判定為失效。 您可以根據 CDN API 來實作您自己的 ContentBuilder 和 TransportHandler (如果 API 不是 REST 型),並設定複寫代理程式,它會利用這些工具讓 CDN 的快取失效。
另請參閱 AEM (CQ) Dispatcher 安全性和 CDN+瀏覽器快取,以及關於 Dispatcher 快取的相關錄製簡報。
如果您使用具有 Touch UI 的 AEM,請不要快取編寫執行個體內容。 如果已為編寫執行個體啟用快取,則必須停用並刪除快取目錄的內容。 如要停用快取,請編輯 author_dispatcher.any
檔案,並修改 /rule
屬性 (/cache
區段),如下所示:
/rules
{
/0000
{ /type "deny" /glob "*"}
}
Dispatcher 可用於編寫執行個體之前,以改善編寫效能。如要設定編寫 Dispatcher,請執行以下操作:
在網頁伺服器中安裝 Dispatcher (Apache 或 IIS 網頁伺服器,請參閱安裝 Dispatcher)。
針對有效的 AEM 發佈執行個體測試新安裝的 Dispatcher。 這麼做可確保達到基準線正確的安裝。
現在,請確定 Dispatcher 能夠透過 TCP/IP 連接到您的編寫執行個體。
將範例 dispatcher.any
檔案取代為 author_dispatcher.any
檔案,這是 Dispatcher 下載隨附的檔案。
在文字編輯器中開啟 author_dispatcher.any
,並進行下列變更:
/hostname
和 /port
(/renders
區段),將它們指向您的編寫執行個體。/docroot
(/cache
區段),將它們指向快取目錄。 如果您正在使用具有 Touch UI 的 AEM,請參閱上面的警告。刪除您在上面設定的 /cache
> /docroot
目錄中的所有現有檔案。
重新啟動網頁伺服器。
在提供的 author_dispatcher.any
設定中,當您安裝 CQ5 Feature Pack、Hotfix 或應用程式程式碼套件時,如果影響到 /libs
或 /apps
下的任何內容,則您必須刪除 Dispatcher 快取中在這些目錄下的快取檔案。 這麼做會確保下次請求時會擷取新升級的檔案,而非舊的快取檔案。
如果您使用先前設定的編寫 Dispatcher,並啟用 Dispatcher 清除代理程式 ,則請執行以下操作: