效能指南

本頁提供如何最佳化AEM部署效能的一般准則。 如果您是初次使用AEM，請先瀏覽下列頁面，再開始閱讀效能准則：

• AEM基本概念
• AEM中的儲存概觀
• 建議的部署
• 技術需求

下圖是AEM可用的部署選項（捲動以檢視所有選項）:

何時使用效能指南

您應在下列情況下使用效能准則：

• 首次部署:規劃首次部署AEM Sites或資產時，請務必了解在配置微內核、節點儲存和資料儲存時可用的選項（與預設設定相比）。例如，將TarMK的資料存放區預設設定變更為檔案資料存放區。
• 升級至新版本:升級至新版本時，請務必了解與執行中環境相較的效能差異。例如，從AEM 6.1升級至6.2，或從AEM 6.0 CRX2升級至6.2 OAK。
• 回應時間緩慢:當選定的Nodestore體系結構不滿足您的要求時，必須了解與其他拓撲選項相比的效能差異。例如，部署TarMK而非MongoMK，或使用檔案資料存放區而非Amazon S3或Microsoft Azure Data Store。
• 新增更多作者:當建議的TarMK拓撲不符合效能需求，且上調製作節點已達到可用的最大容量時，請務必了解與搭配三個或更多製作節點使用MongoMK相比的效能差異。例如，部署MongoMK而非TarMK。
• 新增更多內容:當建議的資料儲存體系結構不符合您的要求時，請務必了解與其他資料儲存選項相比的效能差異。範例：使用Amazon S3或Microsoft Azure資料存放區，而非檔案資料存放區。

簡介

本章提供AEM架構及其最重要元件的一般概述。 此外，也提供開發准則，並說明TarMK和MongoMK基準測試中使用的測試案例。

AEM平台

AEM平台包含下列元件：

如需AEM平台的詳細資訊，請參閱什麼是AEM。

AEM架構

AEM部署有三個重要的組成要素。 內容作者、編輯者和核准者用來建立和檢閱內容的​製作例項。 核准內容後，內容會發佈至名為​發佈例項​的第二個例項類型，使用者可從該類型存取內容。 第三個建置區塊是​Dispatcher，此模組用於處理快取和URL篩選，並安裝在Web伺服器上。 有關AEM架構的其他資訊，請參閱典型部署方案。

微核

微內核在AEM中充當持續性管理器。 與AEM一起使用的微內核有三種類型：TarMK、MongoDB和關係資料庫（受限制支援）。 根據執行個體的用途和您考慮的部署類型，選擇符合您需求的部署。 有關微內核的其他資訊，請參閱建議部署頁。

Nodestore

在AEM中，二進位資料可與內容節點分開儲存。 儲存二進位資料的位置稱為​資料儲存，而內容節點和屬性的位置稱為​節點儲存。

資料儲存

處理大量二進位檔時，建議使用外部資料存放區，而非預設節點存放區，以發揮最大效能。 例如，如果您的專案需要大量媒體資產，將其儲存在檔案或Azure/S3資料存放區下，將比直接儲存在MongoDB中更快地存取。

有關可用配置選項的詳細資訊，請參閱配置節點和資料儲存。

搜尋

本節中列出的是與AEM搭配使用的自訂索引提供者。 若要深入了解索引，請參閱Oak查詢與索引。

開發指南

您應針對AEM開發以​效能和可擴充性為目標。 以下呈現您可遵循的一些最佳實務：

DO

• 分離呈現、邏輯和內容
• 使用現有AEM API(例如：Sling)和工具(例如：復寫)
• 根據實際內容進行開發
• 優化快取性
• 將保存次數最小化(例如：使用暫時性工作流程
• 確定所有HTTP端點都為RESTful
• 限制JCR觀測範圍
• 注意非同步線程

不要

• 如果您可以，請勿直接使用JCR API

• 請勿變更/libs，而是使用覆蓋

• 盡可能不要使用查詢

• 請勿使用Sling系結來取得Java程式碼中的OSGi服務，而應使用：

  • @Reference在DS元件中
  • @Inject在Sling模型中
  • sling.getService()（在Sightly使用類別中）
  • JSP中的sling.getService()
  • 服務追蹤器
  • 直接存取OSGi服務註冊表

如需有關在AEM上開發的詳細資訊，請參閱Developing - The Basics。 如需其他最佳實務，請參閱開發最佳實務。

基準方案

以下詳述的測試案例會用於TarMK、MongoMk和TarMK與MongoMk章節的基準區段。 要查看特定基準測試使用的方案，請閱讀技術規範表中的方案欄位。

單一產品案例

AEM Assets:

• 使用者互動：瀏覽資產/搜尋資產/下載資產/讀取資產中繼資料/更新資產中繼資料/上傳資產/執行上傳資產工作流程
• 執行模式：同時使用者，每位使用者進行單次互動

混合產品案例

AEM Sites +資產：

• 網站使用者互動：閱讀文章頁面/閱讀頁面/建立段落/編輯段落/建立內容頁面/啟用內容頁面/作者搜尋
• Assets使用者互動：瀏覽資產/搜尋資產/下載資產/讀取資產中繼資料/更新資產中繼資料/上傳資產/執行上傳資產工作流程
• 執行模式：同時使用者，每位使用者的混合互動

垂直使用案例情境

媒體:

• 閱讀文章頁面(27.4%)、閱讀頁面(10.9%)、建立工作階段(2.6%)、啟用內容頁面(1.7%)、建立內容頁面(0.4%)、建立段落(4.3%)、編輯段落(0.9%)、影像元件(0.9%)、瀏覽資產(20%)、讀取資產中繼資料(8.5%)、下載資產(4.2%)、搜尋資產(0.2%)、更新資產(2%)(2.4%)、上傳資產(1.2%)、瀏覽專案(4.9%)、讀取專案(6.6%)、專案新增資產(1.2%)、專案新增網站(1.2%)、建立專案(0.1%)、作者搜尋(0.4%)
• 執行模式：同時使用者，每位使用者的混合互動

TarMK

本章介紹TarMK的一般效能指南，指定最低架構需求和設定配置。 也提供了基準測試，以進一步說明。

Adobe建議將TarMK設為客戶在所有部署案例（針對AEM製作和發佈例項）中使用的預設持續性技術。

有關TarMK的詳細資訊，請參閱部署方案和Tar Storage。

TarMK最低架構指南

若要在使用TarMK時建立良好的效能，您應從下列架構開始：

• 一個Author例項
• 兩個發佈例項
• 兩個Dispatcher

下圖是AEM網站和AEM Assets的架構指引。

AEM Sites的Tar架構指引

AEM Assets的Tar架構指引

TarMK設定指引

為獲得良好效能，您應遵循下列設定准則。 有關如何更改設定的說明，請參閱本頁。

TarMK效能基準

技術規範

基準測試是按以下規格執行的：

效能標籤結果

MongoMK

選擇MongoMK永續性後端而不選擇TarMK的主要原因是橫向縮放執行個體。 這表示有兩個或多個活動的作者實例始終運行，並使用MongoDB作為持久性儲存系統。 執行多個製作執行個體的需求，一般是因為單一伺服器的CPU和記憶體容量（支援所有同時編寫活動）已無法持續。

有關TarMK的詳細資訊，請參閱部署方案和Mongo儲存。

MongoMK最低體系結構指南

若要在使用MongoMK時建立良好的效能，您應從下列架構開始：

• 三個製作例項
• 兩個發佈例項
• 三個MongoDB實例
• 兩個Dispatcher

MongoMK設定指南

為獲得良好效能，您應遵循下列設定准則。 有關如何更改設定的說明，請參閱本頁。

MongoMK效能基準

技術規範

基準測試是按以下規格執行的：

效能基準結果

TarMK與MongoMK

在兩者之間進行選擇時，需要考慮的基本規則是TarMK是為效能而設計，而MongoMK是為了擴充性。 Adobe建議將TarMK設為客戶在所有部署案例（針對AEM製作和發佈例項）中使用的預設持續性技術。

選擇MongoMK永續性後端而不選擇TarMK的主要原因是橫向縮放執行個體。 這表示有兩個或多個活動的作者實例始終運行，並使用MongoDB作為持久性儲存系統。 需要執行多個製作執行個體通常是因為單一伺服器的CPU和記憶體容量（支援所有同時編寫活動）已無法持續。

如需TarMK與MongoMK的詳細資訊，請參閱建議部署。

TarMK與MongoMk指南

TarMK的優點

• 專為內容管理應用程式而構建
• 檔案始終一致，可以使用任何基於檔案的備份工具進行備份
• 提供故障轉移機制 — 有關詳細資訊，請參閱冷備用
• 提供高效能和可靠的資料儲存，並且操作開銷最小
• 降低TCO（總擁有成本）

選擇MongoMK的條件

• 一天內連接的指定用戶數：以千計甚至更多
• 同時使用者人數：數百個以上
• 每日資產擷取量：幾十萬甚至更多
• 每天編輯頁面的數量：幾十萬甚至更多
• 每天的搜索量：幾萬甚至更多

TarMK與MongoMK基準

方案1技術規範

方案1效能基準結果

方案2技術規範

方案2效能基準結果

AEM Sites和Assets的架構可擴充性准則

效能指南摘要

本頁所列准則概述如下：

• TarMK與檔案資 料集是大多數客戶建議的架構：

  • 最小拓撲：一個製作例項、兩個發佈例項、兩個Dispatcher
  • 如果共用檔案資料儲存，則開啟無二進位複製

• MongoMK with File Datastore 是建議的架構，可擴充至作者階層的水準：

  • 最小拓撲：三個製作例項、三個MongoDB例項、兩個發佈例項、兩個Dispatcher
  • 如果共用檔案資料儲存，則開啟無二進位複製

• ​​Nodestore應儲存在本地磁碟上，而不是網路連接儲存(NAS)上

• 使用​Amazon S3​時：

  • Amazon S3資料存放區在製作和發佈層級之間共用
  • 必須開啟無二進位複製
  • 「資料存放區垃圾收集」需要先在所有「製作」和「發佈」節點上執行，然後在「製作」上執行第二次

• 除了根據最常見的搜尋建立現成可用的索 引外，還應建立自訂索引

  • Lucene索引應用於自訂索引

• 自訂工作流程可大幅改善效能，例如移除「更新資產」工作流程中的視訊步驟、停用未使用的接聽程式等。

如需詳細資訊，請另閱建議部署頁面。

Business.Adobe.com 資源

Asset Collections Content Intelligence Personalized Communications Dynamic Media Dynamic Forms Digital Signage