性能准则

本页提供了有关如何优化AEM部署性能的一般准则。 如果您是AEM的新用户，请在开始阅读性能指南之前查看以下页面：

• AEM基本概念
• AEM中的存储概述
• 建议的部署
• 技术要求

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

何时使用性能指南

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

• 首次部署：在计划首次部署AEM Sites或Assets时，了解可用的选项很重要。 特别是在配置微内核、节点存储和数据存储时（与默认设置相比）。 例如，将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部署有三个重要的构建块。 此 创作实例 内容作者、编辑者和批准者用于创建和审阅内容。 内容获得批准后，将发布到名为的第二个实例类型。 发布实例 从最终用户访问的位置。 第三个构建基块是 调度程序 这是一个处理缓存和URL过滤的模块，安装在Web服务器上。 有关AEM架构的其他信息，请参阅 典型部署方案.

微内核

微内核在AEM中充当持久性管理器。 AEM使用三种类型的微内核：TarMK、MongoDB和关系数据库（受限制支持）。 根据您的需要选择一种部署类型，具体取决于实例的用途和您考虑的部署类型。 有关微型内核的其他信息，请参见 建议的部署 页面。

Nodestore

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

数据存储

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

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

搜索

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

开发准则

针对AEM定位进行开发 性能和可扩展性. 以下是您可以遵循的最佳实践：

DO

• 应用表示方式、逻辑和内容的分离
• 使用现有AEM API（例如：Sling）和工具（例如：复制）
• 在实际内容的上下文中开发
• 开发以获得最佳可缓存性
• 最大程度地减少保存次数（例如：使用临时工作流）
• 确保所有HTTP端点均为RESTful
• 限制JCR观察的范围
• 注意异步线程

不要

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

• 请勿更改/libs，而是使用叠加

• 尽量不要使用查询

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

  • DS组件中的@Reference
  • 在Sling模型中@Inject用
  • Sightly Use类中的sling.getService()
  • JSP中的sling.getService()
  • ServiceTracker
  • 直接访问OSGi服务注册表

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

基准方案

下面详述的测试场景用于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的一般性能准则，用于指定最低架构要求和设置配置。 此外，还提供了基准测试，以进一步说明问题。

Adobe建议将TarMK作为客户在所有部署场景中使用的默认持久性技术，适用于AEM创作实例和发布实例。

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

TarMK最低架构准则

要在使用TarMK时建立良好的性能，您应该从以下架构开始：

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

以下说明了AEM sites和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的优势

• 专门为内容管理应用程序构建
• 文件始终保持一致，可以使用任何基于文件的备份工具进行备份
• 提供故障切换机制 — 请参见 冷备用 了解更多详细信息
• 以最低的操作开销提供高性能、可靠的数据存储
• 降低TCO（总体拥有成本）

选择MongoMK的标准

• 一天中连接的指定用户数：以千或更多的数量为单位
• 并发用户数：以百计或更多
• 每天的资产摄取量：数十万或更多
• 每天页面编辑量：数十万或更多
• 每天的搜索量：以万或更多

TarMK与MongoMK性能指标评测

场景1技术规范

情景1性能基准结果

场景2技术规范

情景2性能基准结果

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

性能准则摘要

此页面上提供的准则可概括如下：

• 带有文件数据存储的TarMK — 为大多数客户推荐的架构：

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

• 具有文件数据存储的MongoMK — 为创作层的水平可扩展性推荐的体系结构：

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

• Nodestore — 存储在本地磁盘上，而不是网络连接存储(NAS)

• 使用时 Amazon S3：

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

• 除了开箱即用索引之外，还应创建自定义索引 — 基于最常见的搜索

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

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

欲知更多详情，另请阅读 建议的部署 页面。

Business.Adobe.com 资源

Multichannel Communication Auto Text Summarization Personalized Experiences Mobile Forms Dynamic Media Headless Cms