效能准則 performance-guidelines
此頁面提供如何最佳化AEM部署效能的一般准則。 如果您是AEM的新手，請先檢閱下列頁面，再開始閱讀效能准則：
下圖說明適用於AEM的部署選項（捲動以檢視所有選項）：
何時使用效能指南 when-to-use-the-performance-guidelines
請在下列情況下使用效能准則：
- 首次部署：在計畫首次部署AEM Sites或Assets時，請務必瞭解可用的選項。 尤其是在設定Micro Kernel、Node Store和Data Store時（與預設設定相比）。 例如，將TarMK的「資料存放區」預設設定變更為「檔案資料存放區」。
- 升級至新版本：升級至新版本時，請務必瞭解相較於執行中環境的效能差異。 例如，從AEM 6.1升級至6.2，或從AEM 6.0 CRX2升級至6.2 OAK。
- 回應時間緩慢：當選取的節點存放區架構不符合您的需求時，請務必瞭解與其他拓撲選項相比的效能差異。 例如，部署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篩選，並安裝在網頁伺服器上。 如需AEM架構的其他資訊，請參閱 典型部署案例.
微核心 micro-kernels
微核心在AEM中作為持續性管理員。 AEM使用的微核心有三種型別：TarMK、MongoDB和關聯式資料庫（受限制支援）。 選擇適合您需求的部署型別，取決於執行個體的用途以及您考慮的部署型別。 如需關於微核心的其他資訊，請參閱 建議的部署 頁面。
節點存放區 nodestore
在AEM中，二進位資料可與內容節點分開儲存。 儲存二進位資料的位置稱為 資料存放區，而內容節點和屬性的位置稱為 節點存放區.
資料存放區 data-store
在處理大量二進位檔時，建議您使用外部資料存放區，而非預設節點存放區，以發揮最大效能。 例如，如果您的專案需要許多媒體資產，將它們儲存在File或Azure/S3 Data Store底下，可讓您以比直接儲存在MongoDB中更快的速度存取它們。
如需有關可用組態選項的詳細資訊，請參閱 設定節點和資料存放區.
搜尋 search-features
本節所列為搭配AEM使用的自訂索引提供者。 若要進一步瞭解索引，請參閱 Oak查詢和索引.
開發指導方針 development-guidelines
針對AEM目標開發 效能與擴充性. 以下是您可以遵循的最佳實務：
DO
- 套用簡報、邏輯和內容的分離
- 使用現有的AEM API （例如：Sling）和工具（例如：復寫）
- 在實際內容的內容中開發
- 為最佳快取能力而開發
- 將儲存次數減至最少（例如：使用暫時性工作流程）
- 請確定所有HTTP端點均為RESTful
- 限制JCR觀察的範圍
- 留意非同步執行緒
不要
-
如果可以，請勿直接使用JCR API
-
請勿變更/libs，而是使用覆蓋
-
儘量不要使用查詢
-
請勿使用Sling Bindings來取得Java™程式碼中的OSGi服務，而是使用：
- DS元件中的@Reference
- 在Sling模型中@Inject立
- Sightly Use類別中的sling.getService()
- JSP中的sling.getService()
- ServiceTracker
- 直接存取OSGi服務登入
如需有關在AEM上開發的詳細資訊，請閱讀 開發 — 基本知識. 如需其他最佳實務，請參閱 開發最佳實務.
基準案例 benchmark-scenarios
以下詳述的測試場景用於TarMK、MongoMk和TarMK與MongoMk章節的基準區段。 若要檢視特定基準測試使用了哪個案例，請從以下位置閱讀案例欄位： 技術規格 表格。
單一產品情境
AEM Assets：
- 使用者互動：瀏覽資產/搜尋資產/下載資產/讀取資產中繼資料/更新資產中繼資料/上傳資產/執行上傳資產工作流程
- 執行模式：同時存在的使用者，每個使用者的單一互動
混合產品案例
AEM Sites +資產：
- 網站使用者互動：讀取文章頁面/讀取頁面/建立段落/編輯段落/建立內容頁面/啟動內容頁面/作者搜尋
- 資產使用者互動：瀏覽資產/搜尋資產/下載資產/讀取資產中繼資料/更新資產中繼資料/上傳資產/執行上傳資產工作流程
- 執行模式：並行使用者，每個使用者的混合互動
垂直使用案例情境
媒體：
Read Article Page (27.4%), Read Page (10.9%), Create Session (2.6%), Activate Content Page (1.7%), Create Content Page (0.4%), Create Paragraph (4.3%), Edit Paragraph (0.9%), Image Component (0.9%), Browse Assets (20%), Read Asset Metadata (8.5%), Download Asset (4.2%), Search Asset (0.2%), Update Asset Metadata (2.4%), Upload Asset (1.2%), Browse Project (4.9%), Read Project (6.6%), Project Add Asset (1.2%), Project Add Site (1.2%), Create Project (0.1%), Author Search (0.4%)- 執行模式：並行使用者，每個使用者的混合互動
tarmk tarmk
本章提供TarMK的一般效能准則，指定最低架構需求和設定組態。 此外，也提供基準測試，以進一步釐清事實。
Adobe建議將TarMK設為客戶在所有部署案例中使用的預設持續性技術，適用於AEM製作和發佈執行個體。
如需TarMK的詳細資訊，請參閱 部署案例 和 Tar儲存.
TarMK最低架構指導方針 tarmk-minimum-architecture-guidelines
若要在使用TarMK時建立良好的效能，您應該從下列架構開始：
- 一個作者執行個體
- 兩個發佈執行個體
- 兩個Dispatcher
以下說明AEM sites和AEM Assets的架構指導方針。
AEM Sites的Tar架構指導方針
AEM Assets的Tar架構指導方針
TarMK設定指引 tarmk-settings-guideline
為了獲得良好的效能，您應該遵循以下提供的設定准則。 如需如何變更設定的說明， 請參閱此頁面.
TarMK效能基準 tarmk-performance-benchmark
技術規格 technical-specifications
效能標竿測試是依據下列規格執行：
效能標竿結果 performance-benchmark-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-1
TarMK與MongoMK tarmk-vs-mongomk
在兩者之間進行選擇時，要考慮的基本規則是，TarMK是針對效能而設計，而MongoMK則是用於擴充性。 Adobe建議將TarMK設為客戶在所有部署案例中使用的預設持續性技術，適用於AEM製作和發佈執行個體。
選擇MongoMK持續性後端而非TarMK的主要原因是要水平縮放執行個體。 此功能表示需永遠執行兩個或多個作用中的製作執行個體，並使用MongoDB做為持續性儲存系統。 通常需要執行多個製作執行個體，是因為單一伺服器的CPU和記憶體容量（支援所有並行製作活動）已無法持續。
如需TarMK與MongoMK的詳細資訊，請參閱 建議的部署.
TarMK與MongoMk指南 tarmk-vs-mongomk-guidelines
TarMK的優點
- 專門為內容管理應用程式建置
- 檔案始終保持一致，可以使用任何檔案式備份工具進行備份
- 提供容錯移轉機制 — 請參閱 冷待命 以取得更多詳細資料
- 以最低的營運開銷提供高效能和可靠的資料儲存
- 降低總體擁有成本（總體擁有成本）
選擇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和資產的架構擴充性方針 architecture-scalability-guidelines-for-aem-sites-and-assets
效能准則摘要 summary-of-performance-guidelines
此頁面上呈現的准則可歸納如下：
-
含有檔案資料存放區的TarMK — 建議大部分客戶使用的架構：
- 最小拓撲：一個製作執行個體、兩個發佈執行個體、兩個Dispatcher
- 如果檔案資料存放區已共用，會開啟無二進位檔復寫
-
具有檔案資料存放區的MongoMK — 建議用於製作層級水準擴充性的架構：
- 最小拓撲：三個作者執行個體、三個MongoDB執行個體、兩個發佈執行個體、兩個Dispatcher
- 如果檔案資料存放區已共用，會開啟無二進位檔復寫
-
節點存放區 — 儲存在本機磁碟上，而非網路附加儲存裝置(NAS)
-
使用時 Amazon S3：
- Amazon S3資料存放區會在製作和發佈層級之間共用
- 必須開啟無二進位檔復寫
- 資料存放區記憶體回收需要先在所有Author和Publish節點上執行，然後在作者上執行第二次
-
除了現成可用的索引之外，也應建立自訂索引 — 根據最常見的搜尋
- Lucene索引應用於自訂索引
-
自訂工作流程可大幅改善效能 — 移除「更新資產」工作流程中的視訊步驟、停用未使用的接聽程式等。
如需詳細資訊，請閱讀 建議的部署 頁面。