本页提供了有关如何优化AEM部署的一般准则。 如果您是初次使用AEM,请先查看以下页面,然后再开始阅读性能指南:
下图显示了AEM可用的部署选项(滚动以查看所有选项):
AEM 产品 |
拓扑 |
操作系统 |
应用程序服务器 |
JRE |
安全 |
微内核 |
数据存储 |
索引 |
Web 服务器 |
浏览器 |
Marketing Cloud |
站点 |
非HA |
Windows |
CQSE |
Oracle |
LDAP |
焦油 |
区段 |
属性 |
Apache |
Edge |
Target |
资产 |
Publish-HA |
Solaris |
WebLogic |
IBM |
SAML |
MongoDB |
文件 |
Lucene |
IIS |
IE |
Analytics |
社区 |
Author-CS |
红帽 |
WebSphere |
HP |
Oauth |
RDB/Oracle |
S3/Azure |
Solr |
iPlanet |
FireFox |
营销活动 |
表单 |
创作卸载 |
HP-UX |
Tomcat |
|
|
RDB/DB2 |
MongoDB |
|
|
铬黄 |
Social |
移动设备 |
Author-Cluster |
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架构及其最重要的组件。 它还提供了开发准则,并描述了TarMK和MongoMK基准测试中使用的测试方案。
AEM平台包含以下组件:
有关AEM平台的更多信息,请参阅什么是AEM。
AEM部署有三个重要的构建块。 创作实例,内容作者、编辑者和批准者使用该实例创建和审阅内容。 内容获得批准后,会发布到名为Publish Instance的第二个实例类型,最终用户可从中访问该实例。 第三个构建基块是Dispatcher,该模块用于处理缓存和URL过滤,并安装在Web服务器上。 有关AEM架构的其他信息,请参阅典型部署方案。
微内核在AEM中充当持久性管理器。 有三种类型的微内核与AEM一起使用:TarMK、MongoDB和关系数据库(受限制支持)。 请根据您的实例目的和所考虑的部署类型,选择符合您需求的部署。有关微内核的其他信息,请参阅推荐部署页面。
在AEM中,二进制数据可以独立于内容节点进行存储。 存储二进制数据的位置称为数据存储,而内容节点和属性的位置称为节点存储。
Adobe建议将TarMK作为客户用于AEM创作实例和发布实例的默认持久性技术。
关系数据库微内核受到限制支持。 在使用此类型的微内核之前,请联系Adobe客户关怀。
在处理大量二进制文件时,建议使用外部数据存储而不是默认的节点存储,以便最大化性能。 例如,如果您的项目需要大量的媒体资产,则在文件或Azure/S3数据存储下存储这些资产将比直接在MongoDB中存储更快地访问它们。
有关可用配置选项的更多详细信息,请参阅配置节点和数据存储。
Adobe建议选择在Azure或Amazon Web Services(AWS)上使用Adobe Managed Services部署AEM的选项,在该选项中,客户将从具备在这些云计算环境中部署和操作AEM的经验和技能的团队中获益。 请参阅我们的有关Adobe Managed Services的其他文档。
有关如何在Azure或AWS上部署AEM的建议,我们强烈建议在Adobe托管服务之外直接与云提供商或我们选择的支持在云环境中部署AEM的合作伙伴之一合作。 选定的云提供商或合作伙伴负责规模调整规范、设计和实施他们将支持的架构,以满足您的特定性能、负载、可扩展性和安全要求。
有关其他详细信息,还请参见技术要求页面。
此部分中列出的是与AEM一起使用的自定义索引提供程序。 要了解有关索引的更多信息,请参阅Oak查询和索引。
对于大多数部署,Adobe建议使用Lucene索引。 您应仅使用Solr进行专门且复杂的部署中的可扩展性。
您应该针对AEM开发,以实现性能和可扩展性。 以下是您可以遵循的一些最佳实践:
DO
不要
如果可以,请勿直接使用JCR API
不要更改/libs,而是使用叠加图
请勿尽可能使用查询
请勿在Java代码中使用Sling绑定获取OSGi服务,而是使用:
有关在AEM上进行开发的更多详细信息,请参阅开发 — 基础知识。 有关其他最佳实践,请参阅开发最佳实践。
此页面上显示的所有基准测试都已在实验室设置中执行。
下面详述的测试方案用于TarMK、MongoMk和TarMK与MongoMk章节的基准部分。 要查看特定基准测试使用的方案,请阅读技术规范表中的方案字段。
单个产品方案
AEM Assets:
混合产品方案
AEM Sites +资产:
垂直用例方案
媒体:
本章为TarMK提供了一般性能指南,以指定最低架构要求和设置配置。 还提供了基准测试,以便进一步澄清。
Adobe建议将TarMK作为客户在所有部署方案(AEM创作实例和发布实例)中使用的默认持久性技术。
下面介绍的最低架构准则适用于生产环境和高流量站点。 运行AEM所需的****最低规范。
要在使用TarMK时获得良好性能,您应从以下架构开始:
下图显示了AEM网站和AEM Assets的架构准则。
如果共享文件数据存储,则应将无二进制复制设置为ON。
AEM Sites的Tar架构准则
AEM Assets的Tar架构准则
为获得良好性能,您应遵循下面介绍的设置准则。 有关如何更改设置的说明,请参阅此页面。
设置 | 参数 | 值 | 描述 |
Sling作业队列 | queue.maxparallel |
将值设置为CPU核心数的一半。 | 默认情况下,每个作业队列的并发线程数等于CPU核心数。 |
Granite Transient工作流队列 | Max Parallel |
将值设置为CPU核心数的一半 | |
JVM参数 |
|
500000 100000 250000 True |
在AEM启动脚本中添加这些JVM参数,以防止扩展查询使系统过载。 |
Lucene索引配置 |
|
启用 启用 启用 |
有关可用参数的更多详细信息,请参阅此页。 |
数据存储= S3数据存储 |
|
1048576(1MB)或更小 最大堆大小的2-10% |
另请参阅数据存储配置。 |
DAM更新资产工作流 | Transient Workflow |
已选中 | 此工作流用于管理资产的更新. |
DAM元数据写回 | Transient Workflow |
已选中 | 此工作流可管理XMP对原始二进制文件的回写,并在JCR中设置上次修改日期。 |
基准测试是按照以下规范执行的:
创作节点 | |
---|---|
服务器 | 裸机硬件(HP) |
操作系统 | RedHat Linux |
CPU/核心 | 英特尔®至强®CPU E5-2407 @2.40GHz,8核 |
RAM | 32GB |
磁盘 | 磁性 |
Java | OracleJRE版本8 |
JVM堆 | 16GB |
产品 | AEM 6.2 |
Nodestore | TarMK |
数据存储 | 文件DS |
方案 | 单个产品:资产/ 30个并发线程 |
下面显示的数字已被标准化为1作为基准,而不是实际吞吐量数字。
与TarMK相比,选择MongoMK持久性后端的主要原因是横向缩放实例。 这意味着始终运行两个或多个活动创作实例,并将MongoDB用作持久性存储系统。 运行多个创作实例的需求通常是由于单个服务器的CPU和内存容量(支持所有并发创作活动)不再可持续所致。
要在使用MongoMK时获得良好性能,您应从以下架构开始:
在生产环境中, MongoDB将始终用作具有主节点和两个辅助节点的复制副本集。 读取和写入操作将转到主节点,读取操作可以转到辅助节点。 如果存储不可用,则其中一个辅助节点可被仲裁器替换,但MongoDB副本集必须始终由奇数的实例组成。
如果共享文件数据存储,则应将无二进制复制设置为ON。
为获得良好性能,您应遵循下面介绍的设置准则。 有关如何更改设置的说明,请参阅此页面。
设置 | 参数 | 值(默认) | 描述 |
Sling作业队列 | queue.maxparallel |
将值设置为CPU核心数的一半。 | 默认情况下,每个作业队列的并发线程数等于CPU核心数。 |
Granite Transient工作流队列 | Max Parallel |
将值设置为CPU核心数的一半。 | |
JVM参数 |
|
500000 100000 250000 True 60000 |
在AEM启动脚本中添加这些JVM参数,以防止扩展查询使系统过载。 |
Lucene索引配置 |
|
启用 启用 启用 |
有关可用参数的更多详细信息,请参阅此页面。 |
数据存储= S3数据存储 |
|
1048576(1MB)或更小 最大堆大小的2-10% |
另请参阅数据存储配置。 |
DocumentNodeStoreService |
|
2048年 35(25) 20(10) 30(5) 10(3) 4(4) ./cache,size=2048,binary=0,-compact,-compress |
缓存的默认大小设置为256 MB。 会影响执行缓存失效所花费的时间。 |
橡树观察 |
|
最小值和最大值= 20 50000 |
基准测试是按照以下规范执行的:
创作节点 | MongoDB节点 | |
---|---|---|
服务器 | 裸机硬件(HP) | 裸机硬件(HP) |
操作系统 | RedHat Linux | RedHat Linux |
CPU/核心 | 英特尔®至强®CPU E5-2407 @2.40GHz,8核 | 英特尔®至强®CPU E5-2407 @2.40GHz,8核 |
RAM | 32GB | 32GB |
磁盘 | 磁性 — 超过1k IOPS | 磁性 — 超过1k IOPS |
Java | OracleJRE版本8 | 不适用 |
JVM堆 | 16GB | 不适用 |
产品 | AEM 6.2 | MongoDB 3.2 WiredTiger |
Nodestore | MongoMK | 不适用 |
数据存储 | 文件DS | 不适用 |
方案 | 单个产品:资产/ 30个并发线程 | 单个产品:资产/ 30个并发线程 |
下面显示的数字已被标准化为1作为基准,而不是实际吞吐量数字。
在两者之间进行选择时需要考虑的基本规则是,TarMK是为性能而设计的,而MongoMK是为可扩展性而设计的。 Adobe建议将TarMK作为客户在所有部署方案(AEM创作实例和发布实例)中使用的默认持久性技术。
与TarMK相比,选择MongoMK持久性后端的主要原因是横向缩放实例。 这意味着始终运行两个或多个活动创作实例,并将MongoDB用作持久性存储系统。 运行多个创作实例的需求通常是由于单个服务器的CPU和内存容量(支持所有并发创作活动)已不再可持续。
有关TarMK与MongoMK的更多详细信息,请参阅推荐部署。
TarMK的好处
选择MongoMK的标准
下面显示的数字已被标准化为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 | 32GB | 32GB | |
磁盘 | 磁性 — 超过1k IOPS | 磁性 — 超过1k IOPS | |
Java | OracleJRE版本8 | 不适用 | |
JVM堆16GB | 16GB | 不适用 | |
产品 | AEM 6.2 | MongoDB 3.2 WiredTiger | |
Nodestore | TarMK或MongoMK | 不适用 | |
数据存储 | 文件DS | 不适用 | |
方案 |
|
要使用MongoDB的作者数与使用一个TarMK系统的作者数相同,您需要一个具有两个AEM节点的群集。 一个四节点MongoDB群集可以处理一个TarMK实例的作者数量的1.8倍。 一个八节点MongoDB群集可以处理创作次数是一个TarMK实例的2.3倍。
创作TarMK节点 | 创作MongoMK节点 | MongoDB节点 | |
服务器 | AWS c3.8xlarge | AWS c3.8xlarge | AWS c3.8xlarge |
操作系统 | RedHat Linux | RedHat Linux | RedHat Linux |
CPU/核心 | 32 | 32 | 32 |
RAM | 60GB | 60GB | 60GB |
磁盘 | 固态硬盘 — 10k IOPS | 固态硬盘 — 10k IOPS | 固态硬盘 — 10k IOPS |
Java | OracleJRE版本8 | OracleJRE版本8 |
不适用 |
JVM堆16GB | 30GB | 30GB | 不适用 |
产品 | AEM 6.2 | AEM 6.2 | MongoDB 3.2 WiredTiger |
Nodestore | TarMK | MongoMK | 不适用 |
数据存储 | 文件DS | 文件DS |
不适用 |
方案 |
|
本页介绍的准则可概括如下:
对于大多数客户 而言,TarMK与文件数据库是推荐的架构:
MongoMK with File Datastore是 创作层的水平可扩展性推荐的架构:
节点应存储在本地磁盘上,而不是网络连接存储(NAS)上
使用Amazon S3时:
除了基于最常见搜索的现成索引之外,还应 创建自定义索引
自定义工作流可以显着提高性能,例如,删除“更新资产”工作流中的视频步骤,禁用未使用的监听器等。
有关更多详细信息,请参阅推荐的部署页面。