性能指南

本页提供了有关如何优化AEM部署的一般准则。 如果您是初次使用AEM，请先查看以下页面，然后再开始阅读性能指南：

• AEM基本概念
• 存储在AEM中概述
• 推荐的部署
• 技术要求

下图显示了AEM可用的部署选项（滚动以查看所有选项）：

何时使用性能指南

您应在以下情况下使用性能准则：

• 首次部署:当计划首次部署AEM Sites或资产时，请务必了解配置微内核、节点存储和数据存储时可用的选项（与默认设置相比）。例如，将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数据存储，而不是文件数据存储。

简介

本章概述AEM架构及其最重要的组件。 它还提供了开发准则，并描述了TarMK和MongoMK基准测试中使用的测试方案。

AEM平台

AEM平台包含以下组件：

有关AEM平台的更多信息，请参阅什么是AEM。

AEM架构

AEM部署有三个重要的构建块。 创作实例，内容作者、编辑者和批准者使用该实例创建和审阅内容。 内容获得批准后，会发布到名为​Publish Instance​的第二个实例类型，最终用户可从中访问该实例。 第三个构建基块是​Dispatcher，该模块用于处理缓存和URL过滤，并安装在Web服务器上。 有关AEM架构的其他信息，请参阅典型部署方案。

微内核

微内核在AEM中充当持久性管理器。 有三种类型的微内核与AEM一起使用：TarMK、MongoDB和关系数据库（受限制支持）。 请根据您的实例目的和所考虑的部署类型，选择符合您需求的部署。有关微内核的其他信息，请参阅推荐部署页面。

Nodestore

在AEM中，二进制数据可以独立于内容节点进行存储。 存储二进制数据的位置称为​数据存储，而内容节点和属性的位置称为​节点存储。

数据存储

在处理大量二进制文件时，建议使用外部数据存储而不是默认的节点存储，以便最大化性能。 例如，如果您的项目需要大量的媒体资产，则在文件或Azure/S3数据存储下存储这些资产将比直接在MongoDB中存储更快地访问它们。

有关可用配置选项的更多详细信息，请参阅配置节点和数据存储。

搜索

此部分中列出的是与AEM一起使用的自定义索引提供程序。 要了解有关索引的更多信息，请参阅Oak查询和索引。

开发准则

您应该针对AEM开发，以实现​性能和可扩展性。 以下是您可以遵循的一些最佳实践：

DO

• 将呈现、逻辑和内容分离
• 使用现有AEM API(例如：Sling)和工具(例如：复制)
• 根据实际内容进行开发
• 开发最佳可缓存性
• 最大限度地减少保存次数(例如：使用临时工作流)
• 确保所有HTTP端点均为RESTful
• 限制JCR观测范围
• 需要注意异步线程

不要

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

• 不要更改/libs，而是使用叠加图

• 请勿尽可能使用查询

• 请勿在Java代码中使用Sling绑定获取OSGi服务，而是使用：

  • @Reference in a DS component
  • @Inject在Sling模型中
  • sling.getService()Sightly Use类中的
  • JSP中的sling.getService()
  • 服务跟踪器
  • 直接访问OSGi服务注册表

有关在AEM上进行开发的更多详细信息，请参阅开发 — 基础知识。 有关其他最佳实践，请参阅开发最佳实践。

基准方案

下面详述的测试方案用于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存储。

TarMK最低架构指南

要在使用TarMK时获得良好性能，您应从以下架构开始：

• 一个创作实例
• 两个发布实例
• 两个Dispatcher

下图显示了AEM网站和AEM Assets的架构准则。

AEM Sites的Tar架构准则

AEM Assets的Tar架构准则

TarMK设置指南

为获得良好性能，您应遵循下面介绍的设置准则。 有关如何更改设置的说明，请参阅此页面。

TarMK性能基准

技术规范

基准测试是按照以下规范执行的：

性能基准结果

MongoMK

与TarMK相比，选择MongoMK持久性后端的主要原因是横向缩放实例。 这意味着始终运行两个或多个活动创作实例，并将MongoDB用作持久性存储系统。 运行多个创作实例的需求通常是由于单个服务器的CPU和内存容量（支持所有并发创作活动）不再可持续所致。

有关TarMK的更多信息，请参阅部署方案和Mongo存储。

MongoMK最低架构指南

要在使用MongoMK时获得良好性能，您应从以下架构开始：

• 三个创作实例
• 两个发布实例
• 三个MongoDB实例
• 两个Dispatcher

MongoMK设置指南

为获得良好性能，您应遵循下面介绍的设置准则。 有关如何更改设置的说明，请参阅此页面。

MongoMK性能基准

技术规范

基准测试是按照以下规范执行的：

性能基准结果

TarMK与MongoMK

在两者之间进行选择时需要考虑的基本规则是，TarMK是为性能而设计的，而MongoMK是为可扩展性而设计的。 Adobe建议将TarMK作为客户在所有部署方案（AEM创作实例和发布实例）中使用的默认持久性技术。

与TarMK相比，选择MongoMK持久性后端的主要原因是横向缩放实例。 这意味着始终运行两个或多个活动创作实例，并将MongoDB用作持久性存储系统。 运行多个创作实例的需求通常是由于单个服务器的CPU和内存容量（支持所有并发创作活动）已不再可持续。

有关TarMK与MongoMK的更多详细信息，请参阅推荐部署。

TarMK与MongoMk准则

TarMK的好处

• 专为内容管理应用程序而构建
• 文件始终保持一致，并且可以使用任何基于文件的备份工具进行备份
• 提供故障转移机制 — 有关更多详细信息，请参阅冷备用
• 提供高性能、可靠的数据存储，并且运营开销最小
• 降低总体拥有成本（总拥有成本）

选择MongoMK的标准

• 一天内连接的指定用户数：以千计甚至更多
• 并发用户数：数百个或更多
• 每天的资产摄取量：在数十万或更多
• 每日的页面编辑量：在数十万或更多
• 每日搜索量：以万计甚至更多

TarMK与MongoMK基准

情景1技术规范

情景1性能基准结果

情景2技术规范

情景2性能基准结果

AEM Sites和Assets的架构可扩展性准则

性能指南摘要

本页介绍的准则可概括如下：

• 对于大多数客户 而言，TarMK与文件数据库是推荐的架构：

  • 最小拓扑：一个创作实例、两个发布实例、两个Dispatcher
  • 如果共享文件数据存储，则打开无二进制复制

• MongoMK with File Datastore是 创作层的水平可扩展性推荐的架构：

  • 最小拓扑：三个创作实例、三个MongoDB实例、两个Publish实例、两个Dispatcher
  • 如果共享文件数据存储，则打开无二进制复制

• ​​节点应存储在本地磁盘上，而不是网络连接存储(NAS)上

• 使用​Amazon S3​时：

  • Amazon S3数据存储在创作层和发布层之间共享
  • 必须打开无二进制复制
  • 数据存储垃圾收集要求在所有创作和发布节点上先运行一次，然后在创作上再运行一次

• 除了基于最常见搜索的现成索引之外，还应 创建自定义索引

  • Lucene索引应用于自定义索引

• 自定义工作流可以显着提高性能，例如，删除“更新资产”工作流中的视频步骤，禁用未使用的监听器等。

有关更多详细信息，请参阅推荐的部署页面。