Show Menu
主题×

性能准则

本页提供有关如何优化AEM部署性能的一般准则。 如果您是AEM的新用户,请先浏览以下页面,然后再开始阅读性能准则:
下面显示了适用于AEM的部署选项(滚动以查看所有选项):
AEM
产品
拓扑
操作系统
应用程序服务器
JRE
安全
微内核
数据存储
索引
Web 服务器
浏览器
Marketing Cloud
站点
非HA
Windows
CQSE
Oracle
LDAP
Tar
区段
属性
Apache
Edge
目标
资产
Publish-HA
Solaris
WebLogic
IBM
SAML
MongoDB
文件
Lucene
IIS
IE
分析
社区
Author-CS
Red Hat
WebSphere
HP
Oauth
RDB/Oracle
S3/Azure
Solr
iPlanet
FireFox
营销活动
Forms
作者卸载
HP-UX
Tomcat
RDB/DB2
MongoDB
Chrome
Social
移动设备
作者群集
IBM AIX
JBoss
RDB/MySQL
RDBMS
Safari
受众
多站点
ASRP
SUSE
RDB/SQLServer
资产
商务
MSRP
Apple OS
激活
Dynamic Media
JSRP
移动设备
品牌门户
J2E
AoD
LiveFyre
屏幕
文档安全性
流程管理
桌面应用程序
性能准则主要适用于AEM Sites。

何时使用性能准则

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

简介

本章概述了AEM体系架构及其最重要的组件。 它还提供开发指南,并描述TarMK和MongoMK基准测试中使用的测试场景。

AEM平台

AEM平台由以下组件组成:
有关AEM平台的详细信息,请参 阅什么是AEM

AEM架构

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

微内核

在AEM中,Micro Kernel充当持久管理器。 AEM使用的微内核有三种类型:TarMK、MongoDB和关系数据库(受限支持)。 请根据您的实例目的和所考虑的部署类型,选择符合您需求的部署。有关微内核的其他信息,请参阅建议 的部署页

Nodestore

在AEM中,二进制数据可以独立于内容节点存储。 二进制数据的存储位置称为 Data Store ,而内容节点和属性的位置称为 Node Store
Adobe建议TarMK作为AEM作者实例和发布实例的客户使用的默认持久性技术。
关系数据库微内核受限支持。 在使 用此类微内核之前 ,请与Adobe客户关怀部门联系。

Data Store

在处理大量二进制文件时,建议使用外部数据存储而不是默认节点存储,以便最大化性能。 例如,如果您的项目需要大量的媒体资源,则将它们存储在File或Azure/S3 Data Store下比直接存储在MongoDB中更快地访问它们。
有关可用配置选项的更多详细信息,请参 阅配置节点和数据存储
Adobe建议选择使用Adobe Managed services在Azure或Amazon Web Services(AWS)上部署AEM的选项,在该选项中,客户将从在这些云计算环境中部署和操作AEM的经验和技能的团队受益。 请参阅我们 有关Adobe Managed services的其他文档
有关如何在Adobe Managed services之外的Azure或AWS上部署AEM的建议,我们强烈建议直接与云提供商或我们的合作伙伴之一合作,支持在您选择的云环境中部署AEM。 选定的云提供商或合作伙伴负责其将支持的架构的大小调整规范、设计和实施,以满足您的特定性能、负载、可伸缩性和安全性要求。
有关其他详细信息,另请参 阅技术要求 页。

搜索

本节中列出的是与AEM一起使用的自定义索引提供者。 要了解有关索引的更多信息,请参 阅Oak查询和索引
对于大多数部署,Adobe建议使用Lucene索引。 您只应将Solr用于特殊和复杂部署中的可伸缩性。

开发指南

您应针对AEM进行开发,以实现性 能和可伸缩性 。 以下是您可以遵循的一些最佳实践:
DO
  • 应用表示、逻辑和内容的分离
  • 使用现有AEM API(例如:Sling)和工具(例如:复制)
  • 根据实际内容进行开发
  • 开发最佳高速缓存
  • 最小化保存次数(例如:使用临时工作流)
  • 确保所有HTTP端点都是RESTful
  • 限制JCR观测范围
  • 注意异步线程
不要
  • 如果您可以
  • 不更改/libs,而是使用叠加
  • 不要尽可能使用查询
  • 不要使用Sling Bindings获取Java代码中的OSGi服务,而是使用:
    • DS组件中的@Reference
    • @Inclet in a Sling Model
    • sling.getService()Sightly使用类
    • sling.getService()
    • 服务跟踪器
    • 直接访问OSGi服务注册表
有关在AEM上进行开发的更多详细信息,请阅 读开发——基础知识 。 有关其他最佳实践,请参阅开 发最佳实践

基准方案

本页上显示的所有基准测试都已在实验室设置中执行。
下面详述的测试方案用于TarMK、MongoMk和TarMK与MongoMk章节的基准测试部分。 要查看哪个方案用于特定基准测试,请阅读“技术规范”表中的“方 案”字段
单一产品方案
AEM Assets:
  • 用户交互:浏览资产/搜索资产/下载资产/读取资产元数据/更新资产元数据/上传资产/运行上传资产工作流
  • 执行模式:并发用户,每个用户进行一次交互
混合产品方案
AEM Sites + Assets:
  • 站点用户交互:阅读文章页面/阅读页面/创建段落/编辑段落/创建内容页面/激活内容页面/作者搜索
  • 资产用户交互:浏览资产/搜索资产/下载资产/读取资产元数据/更新资产元数据/上传资产/运行上传资产工作流
  • 执行模式:并发用户,每个用户的混合交互
垂直用例方案
媒体:
  • 阅读文章页面(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作者实例和Publish实例)中客户使用的默认持久性技术。
有关TarMK的详细信息,请参 阅部署方案 Tar存储

TarMK最低架构准则

下面介绍的最低架构指南针对生产环境和高流量站点。 这些不 是运行 AEM 所需的最 低规范。
要在使用TarMK时获得良好性能,您应从以下架构开始:
  • 一个作者实例
  • 两个发布实例
  • 两个调度程序
以下说明了AEM站点和AEM资产的架构指南。
如果共享文件数据存储, 应打开无二进制复制。
AEM Sites的Tar架构指南
AEM Assets的Tar架构指南

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 metaData写回 Transient Workflow 已选中 此工作流管理XMP对原始二进制文件的回写,并在JCR中设置上次修改的日期。

TarMK性能基准

技术规范

基准测试是按照以下规范进行的:
作者节点
服务器
裸机硬件(HP)
操作系统
RedHat Linux
CPU/核心
英特尔(R)至强(R)CPU E5-2407 @2.40GHz,8个内核
RAM
32GB
磁盘
磁性
Java
Oracle JRE版本8
JVM堆
16GB
产品
AEM 6.2
Nodestore
TarMK
数据存储
文件DS
方案
单个产品:资产/30个并发线程

性能基准结果

以下数字已标准化为1作为基准,而不是实际吞吐量数字。

MongoMK

选择MongoMK持久性后端到TarMK的主要原因是水平缩放实例。 这意味着有两个或两个以上始终运行的活动作者实例,并将MongoDB用作持久存储系统。 运行多个作者实例的需要通常是由于单个服务器的CPU和内存容量(支持所有并发创作活动)不再可持续。
有关TarMK的详细信息,请参 阅部署方案 Mongo存储

MongoMK最低架构准则

要在使用MongoMK时获得良好性能,您应从以下架构开始:
  • 三个作者实例
  • 两个发布实例
  • 三个MongoDB实例
  • 两个调度程序
在生产环境中,MongoDB将始终用作具有主节点和两个辅助节点的复制副本集。 读和写操作可以转到主映像,读和写操作可以转到辅助映像。 如果存储不可用,可以用仲裁器替换其中一个辅助节点,但MongoDB复制集必须始终由奇数的实例组成。
如果共享文件数据存储, 应打开无二进制复制。

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)
10 (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/核心
英特尔(R)至强(R)CPU E5-2407 @2.40GHz,8个内核
英特尔(R)至强(R)CPU E5-2407 @2.40GHz,8个内核
RAM
32GB
32GB
磁盘
磁性——超过1k IOPS
磁性——超过1k IOPS
Java
Oracle JRE版本8
不适用
JVM堆
16GB
不适用
产品
AEM 6.2
MongoDB 3.2 WiredTiger
Nodestore
MongoMK
不适用
数据存储
文件DS
不适用
方案
单个产品:资产/30个并发线程
单个产品:资产/30个并发线程

性能基准结果

以下数字已标准化为1作为基准,而不是实际吞吐量数字。

TarMKvs MongoMK

在两者之间选择时需要考虑的基本规则是TarMK是为性能而设计的,而MongoMK是为可伸缩性而设计的。 Adobe建议TarMK成为所有部署方案(适用于AEM作者实例和Publish实例)中客户使用的默认持久性技术。
选择MongoMK持久性后端到TarMK的主要原因是水平缩放实例。 这意味着有两个或两个以上始终运行的活动作者实例,并将MongoDB用作持久存储系统。 运行多个作者实例的需要通常是由于单个服务器的CPU和内存容量(支持所有并发创作活动)不再可持续。
有关TarMK与MongoMK的更多详细信息,请参阅建 议的部署

TarMK与MongoMk准则

TarMK的优势
  • 专门为内容管理应用程序构建
  • 文件始终一致,并且可以使用任何基于文件的备份工具进行备份
  • 提供故障转移机制——有关更多详细 信息,请参阅 Cold Standby
  • 提供高性能、可靠的数据存储,并且操作开销最小
  • 更低的总体拥有成本(总体拥有成本)
选择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 32GB 32GB
磁盘 磁性——超过1k IOPS 磁性——超过1k IOPS
Java Oracle JRE版本8 不适用
JVM堆16GB 16GB 不适用
产品 AEM 6.2 MongoDB 3.2 WiredTiger
Nodestore TarMK或MongoMK 不适用
数据存储 文件DS 不适用
方案
单个产品:资产/每次运行30个并发线程

方案1性能基准结果

方案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 60GB 60GB 60GB
磁盘 固态硬盘- 10k IOPS 固态硬盘- 10k IOPS 固态硬盘- 10k IOPS
Java Oracle JRE版本8 Oracle JRE版本8 不适用
JVM堆16GB 30GB 30GB 不适用
产品 AEM 6.2 AEM 6.2 MongoDB 3.2 WiredTiger
Nodestore TarMK MongoMK 不适用
数据存储 文件DS 文件DS 不适用
方案
垂直用例:媒体/ 2000并发线程

方案2性能基准结果

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

性能准则摘要

本页中介绍的准则可概括如下:
  • 对于大多数客户,建议使用 TarMK和文件数据存储:
    • 最小拓扑:一个作者实例、两个Publish实例、两个调度程序
    • 如果共享文件数据存储区,则打开无二进制复制
  • MongoMK with File Datastore (带文件数据存储)是建议的创作层水平可伸缩性架构:
    • 最小拓扑:三个作者实例、三个MongoDB实例、两个Publish实例、两个Dispatcher
    • 如果共享文件数据存储区,则打开无二进制复制
  • 应将Nodestore 存储在本地磁盘上,而不是网络连接存储(NAS)上
  • 使用 Amazon S3时 :
    • Amazon S3数据存储库在作者层和发布层之间共享
    • 必须打开无二进制复制
    • Datastore Garbage Collection要求在所有“作者”和“发布”节点上先运行一次,然后在“作者”上再运行一次
  • 除了基于大多数常见搜索的开箱即用索引外 ,还应创建自定义索引
    • Lucene索引应用于自定义索引
  • 自定义工作流可以大幅提高性能 ,例如,删除“更新资产”工作流中的视频步骤、禁用未使用的监听器等。
有关更多详细信息,另请阅读“推荐 的部署 ”页。