效能指南

本頁提供如何最佳化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

分析

社群

Author-CS

紅帽

WebSphere

HP

Oauth

RDB/Oracle

S3/Azure

Solr

iPlanet

FireFox

行銷活動

表單

作者卸載

HP-UX

Tomcat

RDB/DB2

MongoDB

鉻黃

Social

行動

作者叢集

IBM AIX

JBoss

RDB/MySQL

RDBMS

Safari

對象

多網站

ASRP

SUSE

RDB/SQLServer

資產

商務

MSRP

Apple OS

啟動

Dynamic Media

JSRP

行動

品牌入口網站

J2E

AoD

LiveFyre

畫面

Doc安全性

程式管理

桌面應用程式

注意

效能指引主要適用於AEM Sites。

何時使用效能指南

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

  • 首次部署:規劃首次部署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平台包含下列元件：

chlimage_1

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

AEM架構

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

chlimage_1-1

微核

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

chlimage_1-2

Nodestore

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

注意

Adobe建議將TarMK設為客戶用於AEM製作和發佈執行個體的預設持續性技術。

注意

關係資料庫微內核受限制支援。 使用此類型的微內核之前，請聯繫Adobe客戶服務。

chlimage_1-3

資料儲存

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

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

注意

Adobe建議選擇使用Adobe Managed Services在Azure或Amazon Web Services(AWS)上部署AEM的選項，讓具備在這些雲端運算環境中部署和操作AEM經驗與技能的團隊從中受益。 請參閱我們有關Adobe Managed Services🔗的其他檔案。

如需有關如何在Azure或AWS上部署AEM的建議，強烈建議您直接與雲端提供者或我們其中一位合作夥伴合作，支援在您選擇的雲端環境中部署AEM。 選定的雲提供商或合作夥伴負責規模規格、設計和實施他們將支援的體系結構，以滿足您的特定效能、負載、可擴充性和安全要求。

如需其他詳細資訊，另請參閱技術需求頁面。

搜尋

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

注意

對於大部分部署，Adobe建議使用Lucene索引。 您只應將Solr用於特殊和複雜部署中的可擴充性。

chlimage_1-4

開發指南

您應針對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最低架構指南

注意

以下提供的最低架構指引適用於生產環境和高流量網站。 這些是運行AEM所需的​not最小規範。

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

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

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

注意

如果共用檔案資料儲存區，則應將​ON​開啟無二進位復寫。

AEM Sites的Tar架構指引

chlimage_1-5

AEM Assets的Tar架構指引

chlimage_1-6

TarMK設定指引

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

設定 參數 值 說明
Sling作業佇列 queue.maxparallel 將值設定為CPU內核數的一半。 預設情況下，每個作業隊列的併發線程數等於CPU核心數。
Granite暫時工作流程佇列 Max Parallel 將值設定為CPU內核數的一半
JVM參數

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

500000

100000

250000

True

 在AEM啟動指令碼中添加這些JVM參數，以防止擴展查詢超出系統負載。
Lucene索引配置

CopyOnRead

CopyOnWrite

Prefetch Index Files

已啟用

已啟用

已啟用

 有關可用參數的詳細資訊，請參見此頁。
資料存放區= S3資料存放區

maxCachedBinarySize

cacheSizeInMB

1048576(1MB)或更小

最大堆大小的2-10%

 另請參閱資料儲存配置。
DAM更新資產工作流程 Transient Workflow 已勾選 此工作流程會管理資產的更新。
DAM中繼資料回寫 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個並行執行緒

效能標籤結果

注意

以下數字已標準化為1作為基準，而不是實際吞吐量數字。

chlimage_1-7 chlimage_1-8

MongoMK

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

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

MongoMK最低體系結構指南

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

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

在生產環境中， MongoDB將始終用作具有主節點和兩個輔助節點的複製副本集。 讀取和寫入會轉到主節點，而讀取會轉到輔助節點。 如果儲存不可用，則可以用仲裁程式替換其中一個輔助程式，但MongoDB副本集必須始終由奇數個實例組成。

注意

如果共用檔案資料儲存區，則應將​ON​開啟無二進位復寫。

chlimage_1-9

MongoMK設定指南

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

設定 參數 值（預設值） 說明
Sling作業佇列 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

 在AEM啟動指令碼中添加這些JVM參數，以防止擴展查詢超出系統負載。
Lucene索引配置

CopyOnRead

CopyOnWrite

Prefetch Index Files

已啟用

已啟用

已啟用

 有關可用參數的詳細資訊，請參見此頁。
資料存放區= S3資料存放區

maxCachedBinarySize

cacheSizeInMB

1048576(1MB)或更小

最大堆大小的2-10%

 另請參閱資料儲存配置。
DocumentNodeStoreService

cache

nodeCachePercentage

childrenCachePercentage

diffCachePercentage

docChildrenCachePercentage

prevDocCachePercentage

persistentCache

2048年

35(25)

20(10)

30(5)

10(3)

4(4)

。/cache,size=2048，二進位=0,-compact,-compress

快取的預設大小設定為256 MB。

會影響執行快取失效所花費的時間。
oak-overation

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個並行執行緒

效能基準結果

注意

以下數字已標準化為1作為基準，而不是實際吞吐量數字。

chlimage_1-10 chlimage_1-11

TarMK與MongoMK

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

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

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

TarMK與MongoMk指南

TarMK的優點

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

選擇MongoMK的條件

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

TarMK與MongoMK基準

注意

以下數字已標準化為1作為基準，而不是實際吞吐量數字。

方案1技術規範

製作OAK節點 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效能基準結果

chlimage_1-12

方案2技術規範

注意

若要啟用與使用一個TarMK系統時相同數量的MongoDB作者，您需要具有兩個AEM節點的叢集。 四個節點的MongoDB群集可處理1.8倍於一個TarMK實例的作者數。 八個節點的MongoDB群集可處理的作者數是一個TarMK實例的2.3倍。

製作TarMK節點 製作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
磁碟 固態硬碟 — 10k IOPS 固態硬碟 — 10k IOPS 固態硬碟 — 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效能基準結果

chlimage_1-13

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

chlimage_1-14

效能指南摘要

本頁所列准則概述如下：

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

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

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

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

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

  • 使用​Amazon S3​時：

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

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

    • Lucene索引應用於自訂索引

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

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

本頁內容