Adobe Experience Manager Assets设置包含许多硬件、软件和网络组件。 根据您的部署方案,您可能需要对硬件、软件和网络组件进行特定配置更改,以消除性能瓶颈。
此外,确定并遵守某些硬件和软件优化准则有助于构建一个良好的基础,使您的Experience Manager资产部署能够满足对性能、可扩展性和可靠性的期望。
Experience Manager资产性能不佳可能会影响用户在交互式性能、资产处理、下载速度等方面的体验。
事实上,性能优化是您在为任何项目建立目标量度之前执行的一项基本任务。
以下是一些关键焦点区域,您可以围绕这些区域发现并修复性能问题,然后才能对用户产生影响。
虽然在许多平台上都支持Experience Manager ,但Adobe在Linux和Windows上发现对本机工具的最大支持,这有助于实现最佳性能并简化实施过程。 理想情况下,您应该部署64位操作系统,以满足Experience Manager资产部署的高内存要求。 与任何Experience Manager部署一样,您应尽可能实施TarMK。 虽然TarMK无法扩展到单个创作实例之外,但发现它的性能优于MongoMK。 您可以添加TarMK卸载实例,以提高Experience Manager资产部署的工作流处理能力。
要缩短资产上传时间,请对Java temp目录使用高性能存储。 在Linux和Windows上,可使用RAM驱动器或SSD。 在基于云的环境中,可以使用等效的高速存储类型。 例如,在Amazon EC2中,临时驱动器驱动器可用于temp文件夹。
假设服务器有充足的内存,请配置RAM驱动器。 在Linux上,运行以下命令以创建一个8 GB RAM驱动器:
mkfs -q /dev/ram1 800000
mkdir -p /mnt/aem-tmp
mount /dev/ram1 /mnt/aem-tmp
df -H | grep aem-tmp
在Windows操作系统中,您必须使用第三方驱动程序来创建RAM驱动器,或者只使用高性能存储(如SSD)。
高性能临时卷准备就绪后,设置JVM参数-Djava.io.tmpdir。 例如,您可以将下面的JVM参数添加到AEM的bin/start脚本中的CQ_JVM_OPTS变量中:
-Djava.io.tmpdir=/mnt/aem-tmp
由于Oracle自2015年4月起已停止发布Java 7更新,因此Adobe建议在Java 8上部署Experience Manager资产。 在某些情况下,它显示性能有所改善。
您应设置以下JVM参数:
-XX:+UseConcMarkSweepGC
-Doak.queryLimitInMemory
=500000-Doak.queryLimitReads
=100000-Dupdate.limit
=250000-Doak.fastQuerySize
=true建议所有Experience Manager资产用户将数据存储与区段存储分开。 此外,配置maxCachedBinarySize
和cacheSizeInMB
参数有助于最大化性能。 将maxCachedBinarySize
设置为可在缓存中保存的最小文件大小。 指定用于cacheSizeInMB
内数据存储的内存内缓存大小。 Adobe建议将此值设置为堆总大小的2-10%之间。 但是,负载/性能测试有助于确定理想的设置。
在将大量资产上传到Adobe Experience Manager时,为了允许内存消耗出现意外峰值并防止JVM在出现OutOfMemoryErrors时失败,请减小已配置的缓冲图像缓存的最大大小。 例如,您的系统堆( — Xmx
参数)最大为5 GB,Oak BlobCache设置为1 GB,文档缓存设置为2 GB。 在这种情况下,缓冲的缓存将最大占用1.25 GB和内存,这将仅保留0.75 GB的内存,以备出现意外峰值。
在OSGi Web控制台中配置缓冲的缓存大小。 在https://host:port/system/console/configMgr/com.day.cq.dam.core.impl.cache.CQBufferedImageCache
处,以字节为单位设置属性cq.dam.image.cache.max.memory
。 例如,1073741824为1 GB(1024 x 1024 x 1024 = 1 GB)。
从Experience Manager 6.1 SP1中,如果使用sling:osgiConfig
节点来配置此属性,请确保将数据类型设置为Long。 有关更多详细信息,请参阅CQBufferedImageCache在资产上传期间使用堆。
实施S3或共享文件数据存储有助于在大规模实施中节省磁盘空间并提高网络吞吐量。 有关使用共享数据存储的利弊的更多信息,请参阅资产大小调整指南。
以下S3数据存储配置(org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.cfg
)帮助将12.8 TB的二进制大对象(BLOB)从现有文件数据存储中提取到客户站点的S3数据存储中:
accessKey=<snip>
secretKey=<snip>
s3Bucket=<snip>
s3Region=us-standard
s3EndPoint=<a href="https://s3.amazonaws.com/">s3.amazonaws.com</a>
connectionTimeout=120000
socketTimeout=120000
maxConnections=80
writeThreads=60
concurrentUploadsThreads=30
asyncUploadLimit=30
maxErrorRetry=1000
path=/opt/author/crx-quickstart/repository/datastore
s3RenameKeys=false
s3Encryption=SSE_S3
proactiveCaching=true
uploadRetries=1000
migrateFailuresCount=400
Adobe建议启用HTTPS,因为许多公司都有可嗅探HTTP流量的防火墙,这会对上传和损坏文件造成不利影响。 对于大文件上传,请确保用户已通过有线连接连接到网络,因为WiFi网络会迅速饱和。 有关确定网络瓶颈的准则,请参阅资产大小调整指南。 要通过分析网络拓扑来评估网络性能,请参阅资产网络注意事项。
网络优化策略主要取决于可用带宽量和Experience Manager实例的负载。 常用配置选项(包括防火墙或代理)可帮助提高网络性能。 请牢记以下要点:
尽可能将DAM更新资产工作流设置为“临时”。 该设置可显着减少处理工作流所需的开销,因为在这种情况下,工作流不需要通过常规的跟踪和存档流程。
默认情况下,在Experience Manager 6.3中,DAM更新资产工作流设置为“临时”。在这种情况下,您可以跳过以下过程。
在要配置的Experience Manager实例上打开http://localhost:4502/miscadmin
。
在导航树中,展开工具 > 工作流 > 模型 > dam。
双击DAM更新资产。
从浮动工具面板中,切换到Page选项卡,然后单击Page Properties。
选择临时工作流单击确定。
某些功能不支持临时工作流。 如果您的Experience Manager资产部署需要这些功能,请勿配置临时工作流。
如果不能使用临时工作流,请定期运行工作流清除,以删除已存档的DAM更新资产工作流,以确保系统性能不会下降。
通常,您应每周运行清除工作流。 但是,在资源密集型场景(例如在大规模资产摄取期间)中,您可以更频繁地运行它。
要配置工作流清除,请通过OSGi控制台添加新的AdobeGranite工作流清除配置。 接下来,在每周维护窗口中配置并计划工作流。
如果清除运行过长,则会超时。 因此,您应确保清除作业已完成,以避免由于工作流数量过多而无法完成清除工作流的情况。
例如,在运行大量非瞬态工作流(创建工作流实例节点)后,您可以在临时基础上运行ACS AEM Commons Workflow Remover。 它会立即删除冗余的已完成工作流实例,而不是等待AdobeGranite工作流清除计划程序运行。
默认情况下,Experience Manager运行的最大并行作业数等于服务器上的处理器数。 此设置的问题在于,在负载过重时,所有处理器都被DAM更新资产工作流占用,从而减慢UI响应速度,并阻止Experience Manager运行其他可保护服务器性能和稳定性的进程。 最好通过执行以下步骤将此值设置为服务器上可用处理器的一半:
将队列设置到一半的可用处理器是一个可行的解决方案。 但是,您可能必须增加或减少此数量,才能实现最大吞吐量,并按环境进行调整。 临时工作流和非临时工作流以及其他进程(如外部工作流)有单独的队列。 如果多个队列设置为50%的处理器同时处于活动状态,则系统可以快速过载。 大量使用的队列在各个用户实施中有很大差异。 因此,您可能必须仔细配置它们以实现最高效率,而不牺牲服务器稳定性。
对于大量资源密集型工作流或工作流(如视频转码),您可以将DAM更新资产工作流卸载到第二个创作实例。 通常,卸载的问题是,通过卸载工作流处理而保存的任何加载都会被实例之间来回复制内容的成本所抵销。
从Experience Manager 6.2开始,使用Experience Manager 6.1的功能包,可以使用无二进制复制执行卸载。 在此模型中,创作实例共享公共数据存储,并且只通过转发复制来回发送元数据。 虽然此方法与共享文件数据存储非常适用,但S3数据存储可能存在问题。 由于后台写入线程可能会导致延迟,因此在卸载作业开始之前资产可能尚未写入数据存储。
DAM更新资产工作流包含为任务配置的完整步骤套件,例如Dynamic Media Classic PTIFF生成和InDesign Server集成。 但是,大多数用户可能不需要执行其中的几个步骤。 Adobe建议您创建DAM更新资产工作流模型的自定义副本,并删除任何不必要的步骤。 在这种情况下,请更新DAM更新资产的启动器,以指向新模型。
集中运行DAM更新资产工作流可能会大幅增加文件数据存储的大小。 通过Adobe进行的实验结果表明,如果在8小时内执行大约5500个工作流,则数据存储大小可以增加大约400 GB。
这是临时增加,在您运行数据存储垃圾收集任务后,数据存储将恢复到其原始大小。
通常,数据存储垃圾收集任务与其他计划维护任务一起每周运行。
如果磁盘空间有限,并且集中运行DAM更新资产工作流,请考虑更频繁地计划垃圾收集任务。
客户在其网站中使用各种大小和格式的图像,或将其分发给业务合作伙伴。 由于每个演绎版都会增加资产在存储库中的占用空间,因此Adobe建议谨慎使用此功能。 为了减少处理和存储图像所需的资源量,您可以在运行时生成这些图像,而不是在摄取期间作为演绎版生成这些图像。
许多Sites客户实施了一个图像Servlet,在请求时调整图像大小并裁剪图像,这会对发布实例造成额外负载。 但是,只要可以缓存这些图像,挑战就可以缓解。
另一种方法是使用Dynamic Media Classic技术完全放弃图像处理。 此外,您还可以部署Brand Portal,它不仅从Experience Manager基础架构接管再现生成责任,还接管整个发布层。
如果您自定义DAM更新资产工作流以使用ImageMagick生成演绎版,则Adobe建议您修改位于/etc/ImageMagick/的policy.xml文件。 默认情况下, ImageMagick使用操作系统卷上的整个可用磁盘空间和可用内存。 在policy.xml的policymap
部分内进行以下配置更改以限制这些资源。
<policymap>
<!-- <policy domain="system" name="precision" value="6"/> -->
<policy domain="resource" name="temporary-path" value="/ephemeral0/imagemagick_tmp"/>
<policy domain="resource" name="memory" value="1000MiB"/>
<policy domain="resource" name="map" value="1000MiB"/>
<!-- <policy domain="resource" name="area" value="1gb"/> -->
<policy domain="resource" name="disk" value="10000MiB"/>
<!-- <policy domain="resource" name="file" value="768"/> -->
<policy domain="resource" name="thread" value="1"/>
<policy domain="resource" name="throttle" value="50"/>
<!-- <policy domain="resource" name="time" value="3600"/> -->
</policymap>
此外,在configure.xml文件(或通过设置环境变量MAGIC_TEMPORARY_PATH
)中,将ImageMagick的临时文件夹的路径设置为具有足够空间和IOPS的磁盘分区。
如果ImageMagick使用所有可用磁盘空间,则配置不当可能会使服务器不稳定。 使用ImageMagick处理大型文件所需的策略更改可能会影响Experience Manager性能。 有关更多信息,请参阅安装和配置ImageMagick。
ImageMagick policy.xml
和configure.xml
文件可在/usr/lib64/ImageMagick-*/config/
下找到,而不是/etc/ImageMagick/
下找到。 有关配置文件位置的详细信息,请参阅ImageMagick文档。
如果您在Adobe Managed Services(AMS)上使用Experience Manager,如果您计划处理大量大型PSD或PSB文件,请联系Adobe客户支持。 Experience Manager可能无法处理超过30000 x 23000像素的高分辨率PSB文件。
每当在AEM中修改元数据时,XMP写回会更新原始资产,这会导致以下结果:
所列结果消耗了大量资源。 因此,Adobe建议禁用XMP写回(如果不需要)。
如果选中了运行工作流标志,则导入大量元数据可能会导致资源密集型XMP写回活动。 在精益服务器使用期间规划此类导入,以便不影响其他用户的性能。
在将资产复制到大量发布实例(例如在Sites实施中)时,Adobe建议您使用链复制。 在这种情况下,创作实例会复制到单个发布实例,而该实例又会复制到其他发布实例,从而释放创作实例。
Adobe不建议自动激活资产。 但是,如果需要,Adobe建议将此操作作为工作流的最后一步,通常是DAM更新资产。
确保实施最新的Service Pack和与性能相关的修补程序,因为它们通常包括对系统索引的更新。 请参阅性能调整提示 | 6.x ,用于某些可应用的索引优化,具体取决于您的AEM版本。
为经常运行的查询创建自定义索引。 有关详细信息,请参阅用于分析慢速查询的方法和编制自定义索引。 有关查询和索引最佳实践的其他分析,请参阅查询和索引的最佳实践。
可以对Oak索引配置进行一些优化,以帮助提高Experience Manager资产性能:
更新LuceneIndexProvider配置:
更新索引配置以缩短重新索引时间:
(仅限AEM6.1和6.2)更新ntBaseLucene索引以改进资产删除和移动性能:
浏览到/oak:index/ntBaseLucene/indexRules/nt:base/properties
在/oak:index/ntBaseLucene/indexRules/nt:base/properties下添加两个nt:unstructured节点slingResource和damResolvedPath
在节点上设置以下属性(其中ordered和propertyIndex属性的类型为Boolean):
slingResource
name="sling:resource"
ordered=false
propertyIndex= true
type="String"
damResolvedPath
name="dam:resolvedPath"
ordered=false
propertyIndex=true
type="String"
在/oak:index/ntBaseLucene节点上,设置属性reindex=true
单击Save All
监视error.log以查看何时完成索引:
已完成索引的重新索引:[/oak:index/ntBaseLucene]
您还可以看到,由于reindex属性将返回false,因此在CRXDe中刷新/oak:index/ntBaseLucene节点后,索引即已完成
完成索引后,返回到CRXDe,并将type属性设置为对这两个索引禁用
单击Save All
禁用Lucene文本提取:
如果您的用户不需要搜索资产内容(例如搜索PDF文档中包含的文本),则可以通过禁用此功能来提高索引性能。
在创建生成大结果集的查询时,请使用guessTotal
参数以避免在运行这些查询时内存使用率过高。
在AEM中,存在两个与大文件相关的主要已知问题。 当文件大小超过2 GB时,冷备用同步可能会出现内存不足的情况。 在某些情况下,它会阻止备用同步运行。 在其他情况下,它会导致主实例崩溃。 此方案适用于Experience Manager中任何大于2GB的文件,包括内容包。
同样,当文件在使用共享S3数据存储时达到2GB大小时,文件从缓存完全保留到文件系统可能需要一些时间。 因此,在使用无二进制复制时,可能在复制完成之前没有保留二进制数据。 这种情况可能会导致问题,特别是当数据的可用性很重要时(例如在卸载场景中)。
对于每个Experience Manager部署,建立一个性能测试机制,以便快速识别和解决瓶颈。 以下是需要重点关注的一些关键方面。
对于客户涉及的所有网络性能问题,请执行以下任务:
为了通过高效的CPU利用和负载共享将延迟降至最低并实现高吞吐量,请定期监控Experience Manager实例的性能。 特别是:
guessTotal
优化查询性能。