效能指南

本頁提供如何最佳化部署效能的一般指AEM南。 如果您是新AEM手，請先閱讀下列頁面，再開始閱讀效能准則：

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

以下是可用的部署選項AEM（滾動以查看所有選項）:

AEM 產品	拓撲	作業系統	應用程式伺服器	JRE	安全性	微內核	資料儲存	索引	Web伺服器	瀏覽器	Marketing Cloud
網站	非HA	Windows	CQSE	Oracle	LDAP	Tar	區段	屬性	Apache	Edge	目標
資產	Publish-HA	Solaris	WebLogic	IBM	SAML	MongoDB	檔案	Lucene	IIS	IE	分析
社群	作者-CS	Red Hat	WebSphere	HP	Oauth	RDB/Oracle	S3/Azure	Solr	iPlanet	FireFox	行銷活動
表單	作者卸載	HP-UX	Tomcat			RDB/DB2	MongoDB			Chrome	Social
行動	作者群集	IBM AIX	JBoss			RDB/MySQL	RDBMS			Safari	對象
多網站	ASRP	SUSE				RDB/SQLServer					資產
商務	MSRP	Apple OS									啟動
Dynamic Media	JSRP										行動
品牌入口網站	J2E
AoD
LiveFyre
畫面
檔案安全性
流程管理
桌面應用程式

使用效能指南的時機

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

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

簡介

本章概括介紹了體系結構及其AEM最重要的元件。 它也提供開發指南，並說明TarMK和MongoMK基準測試中使用的測試藍本。

平AEM台

該平AEM台由以下元件組成：

有關平台的詳AEM細資訊，請參AEM閱What is 。

體AEM系結構

部署有三個重要的構AEM成塊。 作者例項，內容作者、編輯者和審核者用來建立和審閱內容。 內容獲得批准後，會發佈到名為​Publish Instance​的第二個實例類型，用戶可從該類型訪問內容。 第三個構建塊是​Dispatcher，它是一個模組，可處理快取和URL過濾，並安裝在webserver上。 有關體系結AEM構的其他資訊，請參見典型部署方案。

微內核

Micro Kernels充當永續性管理器，在中AEM。 使用三種類型的微內核AEM:TarMK、MongoDB和關係資料庫（受限制支援）。 選擇符合您需求的項目取決於您實例的用途以及您考慮的部署類型。 有關微內核的其他資訊，請參見建議部署頁。

Nodestore

在中AEM，二進位資料可以獨立於內容節點儲存。 儲存二進位資料的位置稱為​資料儲存，而內容節點和屬性的位置稱為​節點儲存。

資料儲存

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

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

搜尋

本節列出與一起使用的自訂索引提供AEM者。 若要進一步瞭解索引，請參閱Oak Queries and Indexing。

開發准則

您應針對AEM 效能和可擴充性​進行開發。 以下是您可以遵循的一些最佳實務：

DO

• 將簡報、邏輯和內容分離
• 使用現AEM有API(例如：Sling)和工具(例如：複製)
• 根據實際內容進行開發
• 開發最佳的可快取性
• 將節省的數量減至最少(例如：使用暫時工作流程)
• 確定所有HTTP端點都是RESTful
• 限制JCR觀測範圍
• 注意非同步線程

不要

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

• 不要變更/libs，而是使用覆蓋

• 不要盡可能使用查詢

• 請勿使用Sling Bindings取得Java程式碼中的OSGi服務，而是使用：

  • DS元件中的@Reference
  • @Inject in a Sling Model
  • sling.getService()在Sightly Use Class中
  • sling.getService()在JSP中
  • 服務追蹤器
  • 直接訪問OSGi服務註冊表

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

基準藍本

下面詳述的測試案例用於TarMK、MongoMk和TarMK與MongoMk章節的基準章節。 要查看哪個方案用於特定基準測試，請閱讀技術規格表中的「方案」欄位。

單一產品藍本

AEM Assets:

• 使用者互動：瀏覽資產／搜尋資產／下載資產／讀取資產中繼資料／更新資產中繼資料／上傳資產／執行上傳資產工作流程
• 執行模式：併發用戶，每個用戶單次交互

混合產品藍本

AEM Sites+資產：

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

垂直使用案例藍本

媒體:

• 閱讀文章頁面(27.4%)、閱讀頁面(10.9%)、建立工作階段(2.6%)、啟用內容頁面(1.7%)、建立內容頁面(0.4%)、建立段落(4.3%)、編輯段落(0.9%)、影像元件(0.9%)、瀏覽資產(20%)、讀取資產中繼資料(8.5%)、下載資產(4.2%)、搜尋資產(0.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時建立良好的效能，您應從下列架構開始：

• 一個作者實例
• 兩個發佈例項
• 兩個調度程式

以下是網站和AEM Assets的AEM架構方針。

AEM Sites的Tar架構指南

AEM Assets的Tar架構指南

TarMK設定指南

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

設定	參數	值	說明
Sling Job Queues	queue.maxparallel	將值設定為CPU內核數的一半。	預設情況下，每個作業隊列的併發線程數等於CPU內核數。
Granite暫時工作流程佇列	Max Parallel	將值設定為CPU內核數的一半
JVM參數	Doak.queryLimitInMemory Doak.queryLimitReads Dupdate.limit Doak.fastQuerySize	500000 100000 250000 True	將這些JVM參數新增至AEM啟動指令碼中，以防止擴充查詢超載系統。
Lucene索引配置	CopyOnRead CopyOnWrite Prefetch Index Files	已啟用 已啟用 已啟用	有關可用參數的詳細資訊，請參閱本頁。
資料儲存= S3資料儲存	maxCachedBinarySize cacheSizeInMB	1048576(1MB)或更小 堆大小上限的2-10%	另請參閱資料儲存配置。
DAM更新資產工作流程	Transient Workflow	已勾選	此工作流程管理資產的更新。
DAM MetaData回寫	Transient Workflow	已勾選	此工作流XMP程會管理回寫至原始二進位檔，並在JCR中設定上次修改的日期。

TarMK效能基準

技術規格

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

	作者節點
伺服器	裸機硬體(HP)
作業系統	RedHat Linux
CPU/核心	英特爾®至強®CPU E5-2407 @2.40GHz,8核
RAM	32GB
磁碟	磁性
Java	OracleJRE第8版
JVM堆	16GB
產品	AEM 6.2
Nodestore	TarMK
資料儲存	檔案DS
藍本	單一產品：資產/ 30個併發線程

效能標籤結果

MongoMK

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

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

MongoMK最低體系結構准則

要在使用MongoMK時建立良好的效能，您應從以下體系結構開始：

• 三個作者例項
• 兩個發佈例項
• 3個MongoDB實例
• 兩個調度程式

MongoMK設定准則

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

設定	參數	值（預設值）	說明
Sling Job Queues	queue.maxparallel	將值設定為CPU內核數的一半。	預設情況下，每個作業隊列的併發線程數等於CPU內核數。
Granite暫時工作流程佇列	Max Parallel	將值設定為CPU內核數的一半。
JVM參數	Doak.queryLimitInMemory Doak.queryLimitReads Dupdate.limit Doak.fastQuerySize Doak.mongo.maxQueryTimeMS	500000 100000 250000 True 60000	將這些JVM參數新增至AEM啟動指令碼中，以防止擴充查詢超載系統。
Lucene索引配置	CopyOnRead CopyOnWrite Prefetch Index Files	已啟用 已啟用 已啟用	有關可用參數的詳細資訊，請參閱本頁。
資料儲存= S3資料儲存	maxCachedBinarySize cacheSizeInMB	1048576(1MB)或更小 堆大小上限的2-10%	另請參閱資料儲存配置。
DocumentNodeStoreService	cache nodeCachePercentage childrenCachePercentage diffCachePercentage docChildrenCachePercentage prevDocCachePercentage persistentCache	二零四八年 35(25) 20(10) 30(5) 10(3) 4(4) 。/cache,size=2048,binary=0,-compact,-compress	快取的預設大小設定為256 MB。 對執行快取失效所花費的時間產生影響。
橡樹觀察	thread pool length	最小值與最大值= 20 50000

MongoMK效能基準

技術規格

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

	作者節點	MongoDB節點
伺服器	裸機硬體(HP)	裸機硬體(HP)
作業系統	RedHat Linux	RedHat Linux
CPU/核心	英特爾®至強®CPU E5-2407 @2.40GHz,8核	英特爾®至強®CPU E5-2407 @2.40GHz,8核
RAM	32GB	32GB
磁碟	磁性->1k IOPS	磁性->1k IOPS
Java	OracleJRE第8版	N/A
JVM堆	16GB	不適用
產品	AEM 6.2	MongoDB 3.2 WiredTiger
Nodestore	MongoMK	不適用
資料儲存	檔案DS	不適用
藍本	單一產品：資產/ 30個併發線程	單一產品：資產/ 30個併發線程

效能基準結果

TarMK與MongoMK

在兩種選擇中，需要考慮的基本規則是TarMK是為效能而設計，而MongoMK是為可擴充性而設計。 Adobe建議TarMK為所有部署藍本（包括AEM作者和發佈例項）中客戶使用的預設永續性技術。

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

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

TarMK與MongoMk准則

TarMK的優點

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

選擇MongoMK的標準

• 一天中連接的指名用戶數：數千個或更多
• 並行用戶數：數百個或更多
• 每日資產收錄量：幾十萬甚至更多
• 每天編輯的頁數量：幾十萬甚至更多
• 每日搜尋量：數萬甚至更多

TarMK與MongoMK基準比較

方案1技術規格

	Author OAK Node	MongoDB節點
伺服器	裸機硬體(HP)	裸機硬體(HP)
作業系統	RedHat Linux	RedHat Linux
CPU/核心	英特爾(R)至強(R)CPU E5-2407 @2.40GHz,8核	英特爾(R)至強(R)CPU E5-2407 @2.40GHz,8核
RAM	32GB	32GB
磁碟	磁性->1k IOPS	磁性->1k IOPS
Java	OracleJRE第8版	不適用
JVM堆16GB	16GB	不適用
產品	AEM 6.2	MongoDB 3.2 WiredTiger
Nodestore	TarMK或MongoMK	不適用
資料儲存	檔案DS	不適用
藍本	單一產品：資產／每次執行30個並行執行緒

方案1效能基準結果

方案2技術規格

	編寫TarMK節點	Author MongoMK節點	MongoDB節點
伺服器	AWS c3.8xlarge	AWS c3.8xlarge	AWS c3.8xlarge
作業系統	RedHat Linux	RedHat Linux	RedHat Linux
CPU/核心	32	32	32
RAM	60GB	60GB	60GB
磁碟	SSD - 10k IOPS	SSD - 10k IOPS	SSD - 10k IOPS
Java	OracleJRE第8版	OracleJRE第8版	不適用
JVM堆16GB	30GB	30GB	不適用
產品	AEM 6.2	AEM 6.2	MongoDB 3.2 WiredTiger
Nodestore	TarMK	MongoMK	不適用
資料儲存	檔案DS	檔案DS	不適用
藍本	垂直使用案例：媒體/ 2000個併發線程

方案2效能基準結果

AEM Sites和資產的體系結構可擴充性指南

效能指南摘要

本頁所列准則可總結如下：

• TarMK with File Datastoreis是大多數客戶建議的架構：

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

• MongoMK with File Datastore是建議的作者層橫向擴充架構：

  • 最小拓撲：3個作者例項、3個MongoDB例項、2個發佈例項、2個調度程式
  • 如果檔案資料儲存是共用的，則開啟無二進位複製

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

• 使用​AmazonS3​時：

  • AmazonS3資料存放區在作者和發佈層之間共用
  • 必須開啟無二進位複製
  • Datastore Garbage Collection要求在所有Author和Publish節點上先執行一次，然後在Author上執行第二次

• 除了基於最常見搜索的現成索引外，還應創 建自定義索引

  • Lucene索引應用於自定義索引

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

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