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 頁面),則通常會直接從記憶體擷取檔案,不然頂多是從本機磁碟讀取檔案。靜態網頁伺服器已上市相當長一段時間,因此已經有多種管理和安全管理工具,並且與網路基礎架構高度整合。
如果您使用的是內容管理伺服器 (例如 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 會將檢查該文件是否存在於網頁伺服器的檔案系統中:
為了要瞭解文件是否為最新版本,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 重新擷取前,有許多方法可控制 CDN 快取資源的時長。
明確設定
視 MIME 類型、副檔名、請求類型等,設定 CDN 快取保存特定資源的時長。
到期日和快取控制標題
如果是由上游伺服器傳送,大部分的 CDN 都會遵守 Expires:
和 Cache-Control:
HTTP 標題。例如,可藉由使用 mod_expires Apache 模組來達成這件事。
手動失效
CDN 可透過 Web 介面從快取中移除資源。
API 型失效
大部分的 CDN 也提供 REST 和/或 SOAP API,可從快取中移除資源。
在一般的 AEM 設定中,只要設定副檔名和/或路徑 (可透過上述第 1 和第 2 點達成),即可為經常使用的資源 (例如設計影像和用戶端程式庫) 設定合理的快取期限。部署新版本時,通常需要手動失效。
如果將此方法用於快取受管理的內容,則表示只有在已設定的快取期限到期,並且已再次從 Dispatcher 中擷取文件後,使用者才能看到內容變更。
為了達到更精細的控制,API 型的失效允許您在 Dispatcher 快取失效時將 DN 的快取判定為失效。您可以根據 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 Publish 執行個體來測試新安裝的 Dispatcher,以確保已達成基準正確安裝。
現在,請確定 Dispatcher 能夠透過 TCP/IP 連接到您的編寫執行個體。
將範例 dispatcher.any 檔替換為 Dispatcher 下載內容隨附的 author_dispatcher.any 檔。
在文字編輯器中開啟 author_dispatcher.any
,並進行下列變更:
/hostname
和 /renders
區段的 /port
,以指向您的編寫執行個體。/cache
區段的 /docroot
,以指向快取目錄。如果您正在使用具有 Touch UI 的 AEM,請參閱上面的警告。刪除您在上面設定的 /cache
> /docroot
目錄中的所有現有檔案。
重新啟動網頁伺服器。
請注意,在提供的 author_dispatcher.any
設定中,當您安裝 CQ5 功能套件、Hotfix 或應用程式程式碼套件時,如果 /libs
或 /apps
下的任何內容受到影響,則您必須刪除 Dispatcher 快取中在這些目錄下的快取檔案,以確保下次請求時會擷取新升級的檔案,而非舊的快取檔案。
如果您使用先前設定的編寫 Dispatcher 並啟用 Dispatcher 清除代理程式,請執行以下操作: