性能准则 performance-guidelines
本页提供了有关如何优化AEM部署性能的一般准则。 如果您是AEM的新用户，请在开始阅读性能准则之前阅读以下页面：
下图显示了可用于AEM的部署选项（滚动查看所有选项）：
何时使用性能准则 when-to-use-the-performance-guidelines
在以下情况下使用性能准则：
- 首次部署：在计划首次部署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数据存储，而不是文件数据存储。
简介 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
在处理大量二进制文件时，建议您使用外部数据存储而不是默认节点存储来最大化性能。 例如，如果您的项目需要许多媒体资产，将它们存储在File或Azure/S3数据存储区下，则访问这些媒体资产的速度会比直接将它们存储在MongoDB中更快。
有关可用配置选项的更多详细信息，请参阅 配置节点和数据存储.
搜索 search-features
本节中列出了与AEM一起使用的自定义索引提供程序。 要了解有关索引的更多信息，请参阅 Oak查询和索引.
开发准则 development-guidelines
针对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上进行开发的更多详细信息，请阅读 开发 — 基础知识. 有关其他最佳实践，请参阅 开发最佳实践.
设定方案基准 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
与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-1
TarMK对MongoMK tarmk-vs-mongomk
在两者之间进行选择时，需要考虑的基本规则是TarMK是针对性能而设计的，而MongoMK则是用于可扩展性。 Adobe建议将TarMK作为客户在所有部署场景中使用的默认持久性技术，适用于AEM创作实例和发布实例。
与TarMK相比，选择MongoMK持久性后端的主要原因是要水平缩放实例。 此功能意味着始终运行两个或多个活动的创作实例，并使用MongoDB作为持久性存储系统。 运行多个创作实例的需要通常是由于单个服务器的CPU和内存容量（支持所有并发创作活动）不再可持续。
有关TarMK与MongoMK的更多详细信息，请参阅 建议的部署.
TarMK与MongoMk准则 tarmk-vs-mongomk-guidelines
TarMK的优势
- 专门为内容管理应用程序构建
- 文件始终保持一致，可以使用任何基于文件的备份工具进行备份
- 提供故障转移机制 — 请参阅 冷备用 了解更多详细信息
- 以最低的操作开销提供高性能、可靠的数据存储
- 降低TCO（总体拥有成本）
选择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实例、两个发布实例、两个Dispatcher
- 如果文件数据存储是共享的，则启用无二进制复制
-
Nodestore — 存储在本地磁盘上，而不是网络连接存储(NAS)
-
使用时 Amazon S3：
- Amazon S3数据存储区在创作层和发布层之间共享
- 必须打开无二进制复制
- 数据存储垃圾收集要求首先在所有创作和发布节点上运行一次，然后在创作节点上再运行一次
-
除了开箱即用索引之外，还应创建自定义索引 — 基于最常见的搜索
- Lucene索引应该用于自定义索引
-
自定义工作流可以显着提高性能 — 删除“更新资产”工作流中的视频步骤，禁用未使用的监听器等。
欲知更多详情，另请参阅 建议的部署 页面。