性能准则 performance-guidelines
本页提供了有关如何优化AEM部署的一般准则。 如果您是初次使用AEM，请先查看以下页面，然后再开始阅读性能指南：
下图显示了AEM可用的部署选项（滚动以查看所有选项）：
何时使用性能指南 when-to-use-the-performance-guidelines
您应在以下情况下使用性能准则：
- 首次部署:当计划首次部署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数据存储，而不是文件数据存储。
简介 introduction
本章概述AEM架构及其最重要的组件。 它还提供了开发准则，并描述了TarMK和MongoMK基准测试中使用的测试方案。
AEM平台 the-aem-platform
AEM平台包含以下组件：
有关AEM平台的更多信息，请参阅 什么是AEM.
AEM架构 the-aem-architecture
AEM部署有三个重要的构建块。 的 创作实例 内容作者、编辑者和批准者用于创建和审阅内容。 内容获得批准后，会发布到名为的第二个实例类型 发布实例 最终用户访问页面的位置。 第三个建筑块是 Dispatcher 该模块用于处理缓存和URL过滤，并安装在web服务器上。 有关AEM架构的其他信息，请参阅 典型部署方案.
微核 micro-kernels
微内核在AEM中充当持久性管理器。 有三种类型的微内核与AEM一起使用：TarMK、MongoDB和关系数据库（受限制支持）。 根据实例的用途和您考虑的部署类型，选择一个满足您需求的部署。 有关微内核的其他信息，请参阅 推荐的部署 页面。
Nodestore nodestore
在AEM中，二进制数据可以独立于内容节点进行存储。 存储二进制数据的位置称为 数据存储，而内容节点和属性的位置称为 节点存储.
数据存储 data-store
在处理大量二进制文件时，建议使用外部数据存储而不是默认的节点存储，以便最大化性能。 例如，如果您的项目需要大量的媒体资产，则在文件或Azure/S3数据存储下存储这些资产将比直接在MongoDB中存储更快地访问它们。
有关可用配置选项的更多详细信息，请参阅 配置节点和数据存储.
搜索 search-features
此部分中列出的是与AEM一起使用的自定义索引提供程序。 要了解有关索引的更多信息，请参阅 Oak查询和索引.
开发准则 development-guidelines
您应该针对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服务注册表
基准方案 benchmark-scenarios
下面详述的测试方案用于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
本章为TarMK提供了一般性能指南，以指定最低架构要求和设置配置。 还提供了基准测试，以便进一步澄清。
Adobe建议将TarMK作为客户在所有部署方案（AEM创作实例和发布实例）中使用的默认持久性技术。
TarMK最低架构准则 tarmk-minimum-architecture-guidelines
要在使用TarMK时获得良好性能，您应从以下架构开始：
- 一个创作实例
- 两个发布实例
- 两个Dispatcher
下图显示了AEM网站和AEM Assets的架构准则。
AEM Sites的Tar架构准则
AEM Assets的Tar架构准则
TarMK设置准则 tarmk-settings-guideline
为获得良好性能，您应遵循下面介绍的设置准则。 有关如何更改设置的说明，请 请参阅此页面.
TarMK性能基准 tarmk-performance-benchmark
技术规范 technical-specifications
基准测试是按照以下规范执行的：
性能标记结果 performance-bechmark-results
MongoMK mongomk
与TarMK相比，选择MongoMK持久性后端的主要原因是横向缩放实例。 这意味着始终运行两个或多个活动创作实例，并将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
TarMK与MongoMK tarmk-vs-mongomk
在两者之间进行选择时需要考虑的基本规则是，TarMK是为性能而设计的，而MongoMK是为可扩展性而设计的。 Adobe建议将TarMK作为客户在所有部署方案（AEM创作实例和发布实例）中使用的默认持久性技术。
与TarMK相比，选择MongoMK持久性后端的主要原因是横向缩放实例。 这意味着始终运行两个或多个活动创作实例，并将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 是大多数客户推荐的架构：
- 最小拓扑：一个创作实例、两个发布实例、两个Dispatcher
- 如果共享文件数据存储，则打开无二进制复制
-
带有文件数据存储的MongoMK 是创作层的水平可扩展性推荐的架构：
- 最小拓扑：三个创作实例、三个MongoDB实例、两个Publish实例、两个Dispatcher
- 如果共享文件数据存储，则打开无二进制复制
-
Nodestore 应存储在本地磁盘上，而不是网络连接存储(NAS)上
-
使用 Amazon S3:
- Amazon S3数据存储在创作层和发布层之间共享
- 必须打开无二进制复制
- 数据存储垃圾收集要求在所有创作和发布节点上先运行一次，然后在创作上再运行一次
-
除了开箱即用索引之外，还应创建自定义索引 基于最常见的搜索
- Lucene索引应用于自定义索引
-
自定义工作流可以显着提高性能 例如，删除“更新资产”工作流中的视频步骤，禁用未使用的侦听器，等等。
有关更多详细信息，请参阅 推荐的部署 页面。