效能准則 performance-guidelines
本頁提供如何最佳化AEM部署效能的一般准則。 如果您是初次使用AEM，請先瀏覽下列頁面，再開始閱讀效能准則：
下圖是AEM可用的部署選項（捲動以檢視所有選項）:
何時使用效能准則 when-to-use-the-performance-guidelines
您應在下列情況下使用效能准則：
- 首次部署:規劃首次部署AEM Sites或資產時，請務必了解在配置微內核、節點儲存和資料儲存時可用的選項（與預設設定相比）。 例如，將TarMK的資料存放區預設設定變更為檔案資料存放區。
- 升級至新版本:升級至新版本時，請務必了解與執行中環境相較的效能差異。 例如，從AEM 6.1升級至6.2，或從AEM 6.0 CRX2升級至6.2 OAK。
- 回應時間緩慢:當選定的Nodestore體系結構不滿足您的要求時，必須了解與其他拓撲選項相比的效能差異。 例如，部署TarMK而非MongoMK，或使用檔案資料存放區而非Amazon S3或Microsoft Azure資料存放區。
- 新增更多作者:當建議的TarMK拓撲不符合效能需求，且上調製作節點已達到可用的最大容量時，請務必了解與搭配三個或更多製作節點使用MongoMK相比的效能差異。 例如，部署MongoMK而非TarMK。
- 新增更多內容:當建議的資料儲存體系結構不符合您的要求時，請務必了解與其他資料儲存選項相比的效能差異。 範例：使用Amazon S3或Microsoft Azure資料存放區，而非檔案資料存放區。
簡介 introduction
本章提供AEM架構及其最重要元件的一般概述。 此外，也提供開發准則，並說明TarMK和MongoMK基準測試中使用的測試案例。
AEM平台 the-aem-platform
AEM平台包含下列元件：
如需AEM平台的詳細資訊，請參閱 什麼是AEM.
AEM架構 the-aem-architecture
AEM部署有三個重要的組成要素。 此 製作例項 內容作者、編輯者和批准者用來建立和審閱內容。 內容獲核准後，就會發佈至名為的第二個執行個體類型 發佈例項 從最終用戶訪問的位置。 第三個建築塊是 Dispatcher 此模組可處理快取和URL篩選，並安裝在web伺服器上。 如需AEM架構的其他資訊，請參閱 典型部署方案.
微核 micro-kernels
微內核在AEM中充當持續性管理器。 與AEM一起使用的微內核有三種類型：TarMK、MongoDB和關係資料庫（受限制支援）。 根據執行個體的用途和您考慮的部署類型，選擇符合您需求的部署。 有關微核的其他資訊，請參見 建議的部署 頁面。
Nodestore nodestore
在AEM中，二進位資料可與內容節點分開儲存。 儲存二進位資料的位置稱為 資料儲存，而內容節點和屬性的位置則稱為 節點儲存.
資料儲存 data-store
處理大量二進位檔時，建議使用外部資料存放區，而非預設節點存放區，以發揮最大效能。 例如，如果您的專案需要大量媒體資產，將其儲存在檔案或Azure/S3資料存放區下，將比直接儲存在MongoDB中更快地存取。
如需可用設定選項的詳細資訊，請參閱 配置節點和資料儲存.
搜尋 search-features
本節中列出的是與AEM搭配使用的自訂索引提供者。 要了解有關索引的更多資訊，請參閱 Oak查詢和索引.
開發指導方針 development-guidelines
您應針對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上開發的詳細資訊，請參閱 開發 — 基本. 如需其他最佳實務，請參閱 開發最佳實務.
基準方案 benchmark-scenarios
以下詳述的測試案例會用於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
本章介紹TarMK的一般效能指南，指定最低架構需求和設定配置。 也提供了基準測試，以進一步說明。
Adobe建議將TarMK設為客戶在所有部署案例（針對AEM製作和發佈例項）中使用的預設持續性技術。
如需TarMK的詳細資訊，請參閱 部署方案 和 Tar儲存.
TarMK最低架構指引 tarmk-minimum-architecture-guidelines
若要在使用TarMK時建立良好的效能，您應從下列架構開始：
- 一個Author例項
- 兩個發佈例項
- 兩個Dispatcher
下圖是AEM網站和AEM Assets的架構指引。
AEM Sites的Tar架構指引
AEM Assets的Tar架構指引
TarMK設定指引 tarmk-settings-guideline
為獲得良好效能，您應遵循下列設定准則。 如需如何變更設定的指示， 請參閱本頁.
TarMK效能基準 tarmk-performance-benchmark
技術規格 technical-specifications
基準測試是按以下規格執行的：
效能標籤結果 performance-bechmark-results
MongoMK mongomk
選擇MongoMK永續性後端而不選擇TarMK的主要原因是橫向縮放執行個體。 這表示有兩個或多個活動的作者實例始終運行，並使用MongoDB作為持久性儲存系統。 執行多個製作執行個體的需求，一般是因為單一伺服器的CPU和記憶體容量（支援所有同時編寫活動）已無法持續。
如需TarMK的詳細資訊，請參閱 部署方案 和 Mongo儲存.
MongoMK最低架構准則 mongomk-minimum-architecture-guidelines
若要在使用MongoMK時建立良好的效能，您應從下列架構開始：
- 三個製作例項
- 兩個發佈例項
- 三個MongoDB實例
- 兩個Dispatcher
MongoMK設定准則 mongomk-settings-guidelines
為獲得良好效能，您應遵循下列設定准則。 如需如何變更設定的指示， 請參閱本頁.
MongoMK效能基準 mongomk-performance-benchmark
技術規格 technical-specifications-1
基準測試是按以下規格執行的：
效能基準結果 performance-benchmark-results
TarMK與MongoMK tarmk-vs-mongomk
在兩者之間進行選擇時，需要考慮的基本規則是TarMK是為效能而設計，而MongoMK是為了擴充性。 Adobe建議將TarMK設為客戶在所有部署案例（針對AEM製作和發佈例項）中使用的預設持續性技術。
選擇MongoMK永續性後端而不選擇TarMK的主要原因是橫向縮放執行個體。 這表示有兩個或多個活動的作者實例始終運行，並使用MongoDB作為持久性儲存系統。 需要執行多個製作執行個體通常是因為單一伺服器的CPU和記憶體容量（支援所有同時編寫活動）已無法持續。
如需TarMK與MongoMK的詳細資訊，請參閱 建議的部署.
TarMK與MongoMk准則 tarmk-vs-mongomk-guidelines
TarMK的優點
- 專為內容管理應用程式而構建
- 檔案始終一致，可以使用任何基於檔案的備份工具進行備份
- 提供故障轉移機制 — 請參見 冷待機 如需詳細資訊
- 提供高效能和可靠的資料儲存，並且操作開銷最小
- 降低TCO（總擁有成本）
選擇MongoMK的條件
- 一天內連接的指定用戶數：以千計甚至更多
- 同時使用者人數：數百個以上
- 每日資產擷取量：幾十萬甚至更多
- 每天編輯頁面的數量：幾十萬甚至更多
- 每天的搜索量：幾萬甚至更多
TarMK與MongoMK基準 tarmk-vs-mongomk-benchmarks
方案1技術規範 scenario-technical-specifications
方案1效能基準結果 scenario-performance-benchmark-results
方案2技術規範 scenario-technical-specifications-1
方案2效能基準結果 scenario-performance-benchmark-results-1
適用於AEM Sites和Assets的架構可擴充性指引 architecture-scalability-guidelines-for-aem-sites-and-assets
效能指南摘要 summary-of-performance-guidelines
本頁所列准則概述如下：
-
TarMK與檔案資料存放區 是大多數客戶建議的架構：
- 最小拓撲：一個製作例項、兩個發佈例項、兩個Dispatcher
- 如果共用檔案資料儲存，則開啟無二進位複製
-
MongoMK與檔案資料存放區 是針對製作層級橫向可擴充性的建議架構：
- 最小拓撲：三個製作例項、三個MongoDB例項、兩個發佈例項、兩個Dispatcher
- 如果共用檔案資料儲存，則開啟無二進位複製
-
Nodestore 應儲存在本地磁碟上，而不是網路連接儲存(NAS)上
-
使用時 Amazon S3:
- Amazon S3資料存放區在製作和發佈層級之間共用
- 必須開啟無二進位複製
- 「資料存放區垃圾收集」需要先在所有「製作」和「發佈」節點上執行，然後在「製作」上執行第二次
-
除了現成可用的索引外，還應建立自訂索引 根據最常見的搜尋
- Lucene索引應用於自訂索引
-
定制工作流可以顯著提高效能 例如，移除「更新資產」工作流程中的視訊步驟、停用未使用的監聽器等。
如需詳細資訊，請一併閱讀 建議的部署 頁面。