本頁提供如何最佳化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。
您應在下列情況下使用效能准則:
本章提供AEM架構及其最重要元件的一般概觀。 它也提供開發指南,並說明TarMK和MongoMK基準測試中使用的測試藍本。
AEM平台包含下列元件:
如需AEM平台的詳細資訊,請參閱什麼是AEM。
AEM部署有三個重要的建置區塊。 作者例項,內容作者、編輯者和審核者用來建立和審閱內容。 內容獲得批准後,會發佈到名為Publish Instance的第二個實例類型,用戶可從該類型訪問內容。 第三個構建塊是Dispatcher,它是一個模組,可處理快取和URL過濾,並安裝在webserver上。 如需AEM架構的詳細資訊,請參閱典型部署藍本。
Micro Kernels在AEM中擔任永續性管理員。 AEM使用三種類型的微內核:TarMK、MongoDB和關係資料庫(受限制支援)。 選擇符合您需求的項目取決於您實例的用途以及您考慮的部署類型。 有關微內核的其他資訊,請參見建議部署頁。
在AEM中,二進位資料可獨立於內容節點儲存。 儲存二進位資料的位置稱為資料儲存,而內容節點和屬性的位置稱為節點儲存。
Adobe建議TarMK為AEM Author和Publish執行個體的客戶使用的預設永續性技術。
關係資料庫微內核受到限制支援。 請先聯絡Adobe客戶服務,再使用此類型的微內核。
在處理大量二進位檔案時,建議使用外部資料存放區,而非預設節點儲存區,以發揮最大效能。 例如,如果您的專案需要大量的媒體資產,將它們儲存在檔案或Azure/S3資料存放區下,存取它們的速度會比直接儲存在MongoDB中更快。
有關可用配置選項的詳細資訊,請參閱配置節點和資料儲存。
Adobe建議選擇使用Adobe Managed Services在Azure或Amazon Web Services(AWS)上部署AEM的選項,讓客戶從具備在這些雲端運算環境中部署和操作AEM的經驗和技能的團隊中獲益。 請參閱我們有關Adobe Managed Services](https://www.adobe.com/marketing-cloud/enterprise-content-management/managed-services-cloud-platform.html?aemClk=t)的[其他檔案。
如需有關如何在Adobe Managed Services以外的Azure或AWS上部署AEM的建議,我們強烈建議直接與雲端供應商或我們其中一個合作夥伴合作,支援在您選擇的雲端環境中部署AEM。 選定的雲端供應商或合作夥伴負責其將支援的架構的規模規格、設計和實施,以滿足您的特定效能、負載、可擴充性和安全性要求。
如需詳細資訊,請參閱技術需求頁面。
此區段中列出的是與AEM搭配使用的自訂索引提供者。 若要進一步瞭解索引,請參閱Oak Queries and Indexing。
對於大部分的部署,Adobe建議使用Lucene Index。 您只應將Solr用於特殊和複雜部署的可擴充性。
您應針對AEM進行開發,其目標是效能與延展性。 以下是您可以遵循的一些最佳實務:
DO
不要
如果您可以,請勿直接使用JCR API
不要變更/libs,而是使用覆蓋
不要盡可能使用查詢
請勿使用Sling Bindings取得Java程式碼中的OSGi服務,而是使用:
如需有關在AEM上開發的詳細資訊,請閱讀Developing - The Basics。 如需其他最佳實務,請參閱開發最佳實務。
此頁上顯示的所有基準測試都已在實驗室設定中執行。
下面詳述的測試案例用於TarMK、MongoMk和TarMK與MongoMk章節的基準章節。 要查看哪個方案用於特定基準測試,請閱讀技術規格表中的「方案」欄位。
單一產品藍本
AEM Assets:
混合產品藍本
AEM Sites + Assets:
垂直使用案例藍本
媒體:
本章提供TarMK的一般效能指南,指定最低架構要求和設定組態。 也提供基準測試以供進一步釐清。
Adobe建議TarMK為所有部署案例(包括AEM Author和Publish執行個體)中客戶使用的預設永續性技術。
有關TarMK的詳細資訊,請參閱部署方案和Tar Storage。
以下說明的最低架構准則適用於生產環境和高流量網站。 這些是not執行AEM所需的最小規格。
若要在使用TarMK時建立良好的效能,您應從下列架構開始:
以下是AEM網站和AEM資產的架構方針。
如果檔案資料儲存是共用的,則應將無二進位複製轉為ON。
AEM網站的Tar架構指引
AEM Assets的Tar架構指引
為獲得良好效能,您應遵循下列設定方針。 有關如何更改設定的說明,請參閱本頁。
設定 | 參數 | 值 | 說明 |
Sling Job Queues | queue.maxparallel |
將值設定為CPU內核數的一半。 | 預設情況下,每個作業隊列的併發線程數等於CPU內核數。 |
Granite暫時工作流程佇列 | Max Parallel |
將值設定為CPU內核數的一半 | |
JVM參數 |
|
500000 100000 250000 True |
將這些JVM參數新增至AEM啟動指令碼,以防止擴充查詢超載系統。 |
Lucene索引配置 |
|
已啟用 已啟用 已啟用 |
有關可用參數的詳細資訊,請參閱本頁。 |
資料儲存= S3資料儲存 |
|
1048576(1MB)或更小 堆大小上限的2-10% |
另請參閱資料儲存配置。 |
DAM更新資產工作流程 | Transient Workflow |
已勾選 | 此工作流程管理資產的更新。 |
DAM MetaData回寫 | Transient Workflow |
已勾選 | 此工作流程會管理XMP回寫至原始二進位檔,並在JCR中設定上次修改的日期。 |
基準測試是按照以下規格執行的:
作者節點 | |
---|---|
伺服器 | 裸機硬體(HP) |
作業系統 | RedHat Linux |
CPU/核心 | 英特爾®至強®CPU E5-2407 @2.40GHz,8核 |
RAM | 32GB |
磁碟 | 磁性 |
Java | Oracle JRE第8版 |
JVM堆 | 16GB |
產品 | AEM 6.2 |
Nodestore | TarMK |
資料儲存 | 檔案DS |
藍本 | 單一產品:資產/ 30個併發線程 |
下面顯示的數字已標準化為1作為基線,而不是實際吞吐量數字。
選擇MongoMK持久性後端而非TarMK的主要原因是水準縮放實例。 這表示有兩個或兩個以上的活動作者實例始終運行,並使用MongoDB作為持久性儲存系統。 執行多個作者執行個體的需求,通常是因為單一伺服器的CPU和記憶體容量支援所有並行編寫活動,已不再持續。
有關TarMK的詳細資訊,請參閱部署方案和Mongo Storage。
要在使用MongoMK時建立良好的效能,您應從以下體系結構開始:
在生產環境中, MongoDB將始終用作具有主節點和兩個輔助節點的複製副本集。 讀和寫操作可以轉到主節點,讀操作可以轉到輔助節點。 如果儲存不可用,可以用仲裁程式替換其中一個輔助節點,但MongoDB複製副本集必須始終由奇數個實例組成。
如果檔案資料儲存是共用的,則應將無二進位複製轉為ON。
為獲得良好效能,您應遵循下列設定方針。 有關如何更改設定的說明,請參閱本頁。
設定 | 參數 | 值(預設值) | 說明 |
Sling Job Queues | queue.maxparallel |
將值設定為CPU內核數的一半。 | 預設情況下,每個作業隊列的併發線程數等於CPU內核數。 |
Granite暫時工作流程佇列 | Max Parallel |
將值設定為CPU內核數的一半。 | |
JVM參數 |
|
500000 100000 250000 True 60000 |
將這些JVM參數新增至AEM啟動指令碼,以防止擴充查詢超載系統。 |
Lucene索引配置 |
|
已啟用 已啟用 已啟用 |
有關可用參數的詳細資訊,請參閱本頁。 |
資料儲存= S3資料儲存 |
|
1048576(1MB)或更小 堆大小上限的2-10% |
另請參閱資料儲存配置。 |
DocumentNodeStoreService |
|
二零四八年 35(25) 20(10) 30(5) 10(3) 4(4) 。/cache,size=2048,binary=0,-compact,-compress |
快取的預設大小設定為256 MB。 對執行快取失效所花費的時間產生影響。 |
橡樹觀察 |
|
最小值與最大值= 20 50000 |
基準測試是按照以下規格執行的:
作者節點 | 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 | Oracle JRE第8版 | N/A |
JVM堆 | 16GB | 不適用 |
產品 | AEM 6.2 | MongoDB 3.2 WiredTiger |
Nodestore | MongoMK | 不適用 |
資料儲存 | 檔案DS | 不適用 |
藍本 | 單一產品:資產/ 30個併發線程 | 單一產品:資產/ 30個併發線程 |
下面顯示的數字已標準化為1作為基線,而不是實際吞吐量數字。
在兩種選擇中,需要考慮的基本規則是TarMK是為效能而設計,而MongoMK是為可擴充性而設計。 Adobe建議TarMK為所有部署案例(包括AEM Author和Publish執行個體)中客戶使用的預設永續性技術。
選擇MongoMK持久性後端而非TarMK的主要原因是水準縮放實例。 這表示有兩個或兩個以上的活動作者實例始終運行,並使用MongoDB作為持久性儲存系統。 需要執行多個作者執行個體,通常是因為單一伺服器的CPU和記憶體容量支援所有並行編寫活動,已不再可持續。
有關TarMK與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 | Oracle JRE第8版 | 不適用 | |
JVM堆16GB | 16GB | 不適用 | |
產品 | AEM 6.2 | MongoDB 3.2 WiredTiger | |
Nodestore | TarMK或MongoMK | 不適用 | |
資料儲存 | 檔案DS | 不適用 | |
藍本 |
|
若要啟用與使用一個TarMK系統相同數目的MongoDB作者,您需要具有兩個AEM節點的叢集。 四節點MongoDB群集可處理1.8倍於1個TarMK實例的作者數。 一個8節點MongoDB群集可處理的作者數是一個TarMK實例的2.3倍。
編寫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 | Oracle JRE第8版 | Oracle JRE第8版 |
不適用 |
JVM堆16GB | 30GB | 30GB | 不適用 |
產品 | AEM 6.2 | AEM 6.2 | MongoDB 3.2 WiredTiger |
Nodestore | TarMK | MongoMK | 不適用 |
資料儲存 | 檔案DS | 檔案DS |
不適用 |
藍本 |
|
本頁所列准則可總結如下:
TarMK with File Datastoreis是大多數客戶建議的架構:
MongoMK with File Datastore是建議的作者層橫向擴充架構:
應 將節點儲存在本地磁碟上,而不是網路連接儲存(NAS)
使用Amazon S3時:
除了基於最常見搜索的現成索引外,還應創 建自定義索引
自訂工作流程可大幅改善效能,例如移除「更新資產」工作流程中的視訊步驟、停用未使用的接聽程式等。
如需詳細資訊,請參閱建議部署頁面。