性能指南

本页提供有关如何优化AEM部署性能的一般指南。 如果您是AEM的新手，请先浏览以下页面，然后开始阅读性能指南：

下面显示了AEM的可用部署选项(滚动以视图所有选项):

AEM

产品

拓扑

操作系统

应用程序服务器

JRE

安全

微内核

数据存储

索引

Web 服务器

浏览器

Marketing Cloud

站点

非HA

Windows

CQSE

Oracle

LDAP

焦油

区段

属性

Apache

Edge

目标

资产

Publish-HA

Solaris

WebLogic

IBM

SAML

MongoDB

文件

Lucene

IIS

IE

分析

社区

Author-CS

红帽

WebSphere

HP

Oauth

RDB/Oracle

S3/Azure

Solr

iPlanet

FireFox

营销活动

表单

作者卸载

HP-UX

Tomcat

RDB/DB2

MongoDB

铬黄

Social

移动设备

作者群集

IBM AIX

JBoss

RDB/MySQL

RDBMS

Safari

受众

多站点

ASRP

SUSE

RDB/SQLServer

资产

商务

MSRP

Apple OS

激活

Dynamic Media

JSRP

移动设备

Brand Portal

J2E

AoD

LiveFyre

屏幕

文档安全性

流程管理

桌面应用程序

注意

业绩指引主要适用于AEM Sites。

何时使用性能准则

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

  • 首次部署:首次计划部署AEM Sites或资产时，请务必了解配置微内核、节点存储和数据存储时可用的选项（与默认设置相比）。例如，将TarMK的数据存储的默认设置更改为文件数据存储。
  • 升级到新版本:升级到新版本时，了解与运行环境相比的性能差异很重要。例如，从AEM 6.1升级到6.2，或从AEM 6.0 CRX2升级到6.2 OAK。
  • 响应时间很慢:当选定的Nodestore体系结构不符合您的要求时，了解与其他拓扑选项相比的性能差异非常重要。例如，部署TarMK而不是MongoMK，或者使用文件数据存储而不是AmazonS3或Microsoft Azure数据存储。
  • 添加更多作者:当建议的TarMK拓扑不满足性能要求并且调整作者节点已达到最大可用容量时，了解与使用MongoMK和三个或更多作者节点相比的性能差异非常重要。例如，部署MongoMK而不是TarMK。
  • 添加更多内容:当建议的数据存储体系结构不符合您的要求时，了解与其他数据存储选项相比的性能差异非常重要。示例：使用AmazonS3或Microsoft Azure Data Store而不是文件数据存储。

简介

本章概括介绍了AEM体系结构及其最重要的组件。 它还提供开发指南，并描述TarMK和MongoMK基准测试中使用的测试方案。

AEM平台

AEM平台由以下组件组成：

chlimage_1

有关AEM平台的详细信息，请参见什么是AEM。

AEM体系架构

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

chlimage_1-1

微内核

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

chlimage_1-2

Nodestore

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

注意

Adobe建议TarMK作为客户用于AEM作者实例和发布实例的默认持久性技术。

注意

关系数据库微内核受到限制支持。 在使用此类型的微内核之前，请与Adobe客户关怀联系。

chlimage_1-3

数据存储

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

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

注意

Adobe建议选择使用Adobe Managed Services在Azure或AmazonWeb服务(AWS)上部署AEM的选项，在该选项中，客户将从具备在这些云计算环境中部署和操作AEM的经验和技能的团队受益。 请参阅我们的有关Adobe Managed Services的其他文档。

有关如何在Azure或AWS上部署AEM的建议，我们强烈建议在Adobe托管服务之外直接与云提供商或我们的合作伙伴之一合作，在您选择的云环境中支持部署AEM。 选定的云提供商或合作伙伴负责规模规范、设计和实施他们将支持的架构，以满足您的特定性能、负载、可扩展性和安全要求。

有关其他详细信息，另请参见技术要求页。

搜索

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

注意

对于大多数部署，Adobe建议使用Lucene索引。 您只应将Solr用于特殊和复杂部署中的可伸缩性。

chlimage_1-4

开发指南

您应该为AEM开发以实现​性能和可伸缩性​为目标。 以下是您可以遵循的许多最佳实践：

DO

  • 应用表示、逻辑和内容的分离
  • 使用现有AEM API(例如：Sling)和工具(例如：复制)
  • 根据实际内容进行开发
  • 开发最佳可缓存性
  • 最小化保存次数(例如：使用临时工作流)
  • 确保所有HTTP端点都是RESTful
  • 限制JCR观测范围
  • 注意异步线程

不要

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

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

  • 不要尽可能使用查询

  • 不要使用Sling Bindings获取Java代码中的OSGi服务，而应使用：

    • DS组件中的@引用
    • @Incret in a Sling Model
    • sling.getService()Sightly Use类
    • 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最低体系结构准则

注意

下面介绍的最低体系结构指南针对生产环境和高流量站点。 这些是运行AEM所需的最小规范​不。

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

  • 一个作者实例
  • 两个发布实例
  • 两个调度程序

以下是AEM站点和AEM Assets的架构指南。

注意

如果共享文件数据存储区，应将无二进制复制设置为​ON。

AEM Sites的Tar架构指南

chlimage_1-5

AEM Assets的Tar架构指南

chlimage_1-6

TarMK设置指南

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

设置 参数 值 描述
Sling作业队列 queue.maxparallel 将值设置为CPU核心数的一半。 默认情况下，每个作业队列的并发线程数等于CPU核心数。
Granite临时工作流队列 Max Parallel 将值设置为CPU核心数的一半
JVM参数

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

500000

100000

250000

True

 在AEM开始脚本中添加这些JVM参数，以防止扩展查询过载系统。
Lucene索引配置

CopyOnRead

CopyOnWrite

Prefetch Index Files

启用

启用

启用

 有关可用参数的详细信息，请参阅此页。
数据存储= S3数据存储

maxCachedBinarySize

cacheSizeInMB

1048576(1MB)或更小

最大堆大小的2-10%

 另请参阅数据存储配置。
DAM更新资产工作流 Transient Workflow 已选中 此工作流用于管理资产的更新.
DAM元数据写回 Transient Workflow 已选中 此工作流管理XMP写回到原始二进制文件，并在JCR中设置上次修改日期。

TarMK性能基准

技术规范

基准测试根据以下规范执行：

作者节点
服务器 裸机硬件(HP)
操作系统 RedHat Linux
CPU/核心 英特尔®至强®CPU E5-2407 @2.40GHz,8核
RAM 32 GB
磁盘 磁性
Java OracleJRE版本8
JVM堆 16 GB
产品 AEM 6.2
Nodestore TarMK
数据存储 文件DS
方案 单一产品：资产/ 30个并发线程

性能基准结果

注意

下面显示的数字已标准化为1作为基准，而不是实际吞吐量数字。

chlimage_1-7 chlimage_1-8

MongoMK

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

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

MongoMK最低体系结构准则

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

  • 三个作者实例
  • 两个发布实例
  • 三个MongoDB实例
  • 两个调度程序
注意

在生产环境中，MongoDB将始终用作具有主节点和两个辅助节点的复制副本集。 读和写操作将转到主文件夹，读操作可转到辅助文件夹。 如果存储不可用，其中一个辅助节点可以替换为仲裁程序，但MongoDB副本集必须始终由奇数的实例组成。

注意

如果共享文件数据存储区，应将无二进制复制设置为​ON。

chlimage_1-9

MongoMK设置准则

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

设置 参数 值（默认值） 描述
Sling作业队列 queue.maxparallel 将值设置为CPU核心数的一半。 默认情况下，每个作业队列的并发线程数等于CPU核心数。
Granite临时工作流队列 Max Parallel 将值设置为CPU核心数的一半。
JVM参数

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

Doak.mongo.maxQueryTimeMS

500000

100000

250000

True

60000

 在AEM开始脚本中添加这些JVM参数，以防止扩展查询过载系统。
Lucene索引配置

CopyOnRead

CopyOnWrite

Prefetch Index Files

启用

启用

启用

 有关可用参数的详细信息，请参阅此页。
数据存储= S3数据存储

maxCachedBinarySize

cacheSizeInMB

1048576(1MB)或更小

最大堆大小的2-10%

 另请参阅数据存储配置。
DocumentNodeStoreService

cache

nodeCachePercentage

childrenCachePercentage

diffCachePercentage

docChildrenCachePercentage

prevDocCachePercentage

persistentCache

2048

35(25)

20(10)

30(5)

十(3)

4(4)

。/cache,size=2048,binary=0,-compact,-compress

缓存的默认大小设置为256 MB。

影响执行缓存失效所花费的时间。
橡树观察

thread pool

length

最小和最大= 20

50000

MongoMK性能基准

技术规范

基准测试根据以下规范执行：

作者节点 MongoDB节点
服务器 裸机硬件(HP) 裸机硬件(HP)
操作系统 RedHat Linux RedHat Linux
CPU/核心 英特尔®至强®CPU E5-2407 @2.40GHz,8核 英特尔®至强®CPU E5-2407 @2.40GHz,8核
RAM 32 GB 32 GB
磁盘 磁性——超过1k IOPS 磁性——超过1k IOPS
Java OracleJRE版本8 不适用
JVM堆 16 GB 不适用
产品 AEM 6.2 MongoDB 3.2 WiredTiger
Nodestore MongoMK 不适用
数据存储 文件DS 不适用
方案 单一产品：资产/ 30个并发线程 单一产品：资产/ 30个并发线程

性能基准结果

注意

下面显示的数字已标准化为1作为基准，而不是实际吞吐量数字。

chlimage_1-10 chlimage_1-11

TarMK与MongoMK

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

选择MongoMK持久性后端而非TarMK的主要原因是水平缩放实例。 这意味着始终运行两个或更多个活动的作者实例，并将MongoDB用作持久性存储系统。 需要运行多个创作实例通常是因为单个服务器的CPU和内存容量已不再可持续，它支持所有并发创作活动。

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

TarMK与MongoMk准则

TarMK的优势

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

选择MongoMK的标准

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

TarMK与MongoMK基准

注意

下面显示的数字已标准化为1作为基准，而不是实际吞吐量数字。

方案1技术规范

创作OAK节点 MongoDB节点
服务器 裸机硬件(HP) 裸机硬件(HP)
操作系统 RedHat Linux RedHat Linux
CPU/核心 英特尔(R)至强(R)CPU E5-2407 @2.40GHz,8核 英特尔(R)至强(R)CPU E5-2407 @2.40GHz,8核
RAM 32 GB 32 GB
磁盘 磁性——超过1k IOPS 磁性——超过1k IOPS
Java OracleJRE版本8 不适用
JVM堆16GB 16 GB 不适用
产品 AEM 6.2 MongoDB 3.2 WiredTiger
Nodestore TarMK或MongoMK 不适用
数据存储 文件DS 不适用
方案


单一产品：资产／每次运行30个并发线程

方案1性能基准结果

chlimage_1-12

方案2技术规范

注意

要使MongoDB的作者数与使用一个TarMK系统的作者数相同，您需要一个包含两个AEM节点的群集。 四节点MongoDB群集可处理作者数的1.8倍于一个TarMK实例。 八个节点MongoDB群集可处理作者数的2.3倍于一个TarMK实例。

作者TarMK节点 作者MongoMK节点 MongoDB节点
服务器 AWS c3.8xlarge AWS c3.8xlarge AWS c3.8xlarge
操作系统 RedHat Linux RedHat Linux RedHat Linux
CPU/核心 32 32 32
RAM 60 GB 60 GB 60 GB
磁盘 SSD - 10k IOPS SSD - 10k IOPS SSD - 10k IOPS
Java OracleJRE版本8
OracleJRE版本8		 不适用
JVM堆16GB 30 GB 30 GB 不适用
产品 AEM 6.2 AEM 6.2
MongoDB 3.2 WiredTiger
Nodestore TarMK MongoMK
不适用
数据存储 文件DS
文件DS
不适用
方案



垂直用例：媒体/ 2000个并发线程

方案2性能基准结果

chlimage_1-13

AEM Sites和资产的架构可伸缩性准则

chlimage_1-14

性能指南摘要

本页介绍的准则概述如下：

  • TarMK with File Datastore是大多数客户的推荐架构：

    • 最小拓扑：一个作者实例、两个Publish实例、两个Dispatcher
    • 如果共享文件数据存储区，则启用无二进制复制

  • MongoMK with File Datastore是建议的创作层水平可伸缩性架构：

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

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

  • 使用​AmazonS3​时：

    • AmazonS3数据存储区在作者层和发布层之间共享
    • 必须打开无二进制复制
    • Datastore Garbage Collection要求在所有“作者”和“发布”节点上先运行一次，然后在“作者”上再运行一次

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

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

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

有关详细信息，请阅读建议的部署页。

在此页面上