性能准则 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部署有三个重要的构建块。 内容作者、编辑者和批准者用于创建和审查内容的 创作实例。 内容获得批准后，将发布到名为 Publish实例 的第二个实例类型，最终用户可从此处访问该内容。 第三个构建基块是 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观察的范围
- 请注意异步线程
DO NOT
-
如果可以，请不要直接使用JCR API
-
请勿更改/libs，而是使用叠加
-
尽量不要使用查询
-
请勿使用Sling绑定在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创作实例和Publish实例。
TarMK最低架构准则 tarmk-minimum-architecture-guidelines
要在使用TarMK时建立良好的性能，您应该从以下架构开始：
- 一个创作实例
- 两个Publish实例
- 两个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和内存容量（支持所有并发创作活动）不再可持续。
MongoMK最低架构准则 mongomk-minimum-architecture-guidelines
要在使用MongoMK时建立良好的性能，您应该从以下架构开始：
- 三个作者实例
- 两个Publish实例
- 三个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创作实例和Publish实例。
与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文件数据存储 — 针对大多数客户推荐的体系结构：
- 最小拓扑：一个创作实例、两个Publish实例、两个Dispatcher
- 如果文件数据存储是共享的，则启用无二进制复制
-
具有文件数据存储的MongoMK — 为创作层的水平可扩展性推荐的体系结构：
- 最小拓扑：三个创作实例、三个MongoDB实例、两个Publish实例、两个Dispatcher
- 如果文件数据存储是共享的，则启用无二进制复制
-
节点存储 — 存储在本地磁盘上，而不是网络连接存储(NAS)
-
使用 Amazon S3 时：
- Amazon S3数据存储区在创作层和Publish层之间共享
- 必须打开无二进制复制
- 数据存储垃圾收集要求先在所有Author和Publish节点上运行一次，然后再在Author上运行一次
-
除了开箱即用索引之外，还应创建自定义索引 — 基于最常见的搜索
- Lucene索引应该用于自定义索引
-
自定义工作流可以显着提高性能 — 删除“更新资产”工作流中的视频步骤，禁用未使用的监听程序等。
有关更多详细信息，另请阅读推荐的部署页面。