效能准則 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。
- 回應時間緩慢：當選取的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篩選的模組，並安裝在網頁伺服器上。 如需AEM架構的其他資訊，請參閱一般部署案例。
微核心 micro-kernels
微核心可充當AEM中的持續性管理員。 AEM使用的微核心有三種型別：TarMK、MongoDB和關聯式資料庫（受限制支援）。 選擇適合您需求的部署型別，取決於執行個體的用途以及您考慮的部署型別。 如需微核心的其他資訊，請參閱建議的部署頁面。
節點存放區 nodestore
在AEM中，二進位資料可與內容節點分開儲存。 儲存二進位資料的位置稱為資料存放區，而內容節點和屬性的位置稱為節點存放區。
資料存放區 data-store
在處理大量二進位檔時，建議您使用外部資料存放區，而非預設節點存放區，以發揮最大效能。 例如，如果您的專案需要許多媒體資產，將它們儲存在「檔案」或「Azure/S3資料存放區」下，可讓您比直接將它們儲存在MongoDB中更快存取它們。
如需有關可用組態選項的詳細資訊，請參閱設定節點與資料存放區。
搜尋 search-features
本節所列為搭配AEM使用的自訂索引提供者。 若要進一步瞭解建立索引，請參閱Oak查詢與索引。
開發指導方針 development-guidelines
針對AEM開發，以尋求效能與擴充性。 以下是您可以遵循的最佳實務：
DO
- 套用簡報、邏輯和內容的分離
- 使用現有的AEM API （例如：Sling）和工具（例如：復寫）
- 在實際內容的內容中開發
- 為最佳快取能力而開發
- 將儲存次數減至最少（例如：使用暫時性工作流程）
- 請確定所有HTTP端點均為RESTful
- 限制JCR觀察的範圍
- 留意非同步執行緒
DO NOT
-
如果可以，請勿直接使用JCR API
-
請勿變更/libs，而是使用覆蓋
-
儘量不要使用查詢
-
請勿使用Sling Bindings來取得Java™程式碼中的OSGi服務，而是使用：
- DS元件中的@Reference
- 在Sling模型中@Inject立
- Sightly Use類別中的sling.getService()
- JSP中的sling.getService()
- ServiceTracker
- 直接存取OSGi服務登入
基準案例 benchmark-scenarios
以下詳述的測試場景用於TarMK、MongoMk和TarMK與MongoMk章節的基準區段。 若要檢視哪一個案例用於特定基準測試，請從技術規格表格中讀取[案例]欄位。
單一產品案例
AEM Assets：
- 使用者互動：瀏覽Assets /搜尋Assets /下載資產/讀取資產中繼資料/更新資產中繼資料/上傳資產/執行上傳資產工作流程
- 執行模式：同時存在的使用者，每個使用者的單一互動
混合產品案例
AEM Sites + Assets：
- 網站使用者互動：讀取文章頁面/讀取頁面/建立段落/編輯段落/建立內容頁面/啟動內容頁面/作者搜尋
- Assets使用者互動：瀏覽Assets /搜尋Assets /下載資產/讀取資產中繼資料/更新資產中繼資料/上傳資產/執行上傳資產工作流程
- 執行模式：並行使用者，每個使用者的混合互動
垂直使用案例情境
媒體：
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最低架構指導方針 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和Assets的架構擴充性方針 architecture-scalability-guidelines-for-aem-sites-and-assets
效能准則摘要 summary-of-performance-guidelines
此頁面上呈現的准則可歸納如下：
-
TarMK與File Datastore — 建議大部分客戶的架構：
- 最小拓撲：一個製作執行個體、兩個發佈執行個體、兩個Dispatcher
- 如果檔案資料存放區已共用，會開啟無二進位檔復寫
-
具有檔案資料存放區的MongoMK — 建議的Author層級水準擴充性架構：
- 最小拓撲：三個作者執行個體、三個MongoDB執行個體、兩個發佈執行個體、兩個Dispatcher
- 如果檔案資料存放區已共用，會開啟無二進位檔復寫
-
Nodestore — 儲存在本機磁碟上，而非網路附加儲存裝置(NAS)
-
使用 Amazon S3 時：
- Amazon S3資料存放區會在製作和發佈層級之間共用
- 必須開啟無二進位檔復寫
- 資料存放區記憶體回收需要先在所有Author和Publish節點上執行，然後在作者上執行第二次
-
除了現成可用的索引之外，應該建立自訂索引 — 根據最常見的搜尋
- Lucene索引應用於自訂索引
-
自訂工作流程可大幅改善效能 — 移除「更新資產」工作流程中的視訊步驟、停用未使用的接聽程式等。
如需詳細資訊，請閱讀建議的部署頁面。