Show Menu
主题×

资产性能指南

数字资产管理通常用于性能重要的情况;但是,典型的DAM设置包含许多可能影响性能的硬件和软件组件。 本文档提供以下内容:
  • 有关为新的数字资产管理设置确定最佳硬件大小的信息
  • 面向希望对DAM实例进行性能问题故障诊断的软件开发人员的信息

性能问题

数字资产管理中的糟糕性能可能会通过以下三种方式影响用户体验:交互性能、资产处理和下载速度。 要提高性能,必须正确衡量观察到的性能并建立目标指标。
1. 交互式搜索和浏览 用户正在搜索资产或浏览DAM查找器,并抱怨响应时间较慢或搜索结果不会立即显示。 这是一个交互式性能问题。
交互性能是根据页面响应时间来衡量的。 这是从接收HTTP请求到关闭HTTP响应所花费的时间,这可以从请求日志文件中确定。 典型的目标性能是低于两秒的页面响应时间。
2. 资产处理 :资产处理问题是当用户上传资产时,在将资产轻松转换并引入AEM DAM之前,需要几分钟时间。
资产处理性能以平均工作流进程完成时间衡量。 这是从调用资产更新工作流流程到完成该流程所花费的时间,这可以通过工作流报告用户界面来确定。 典型的目标性能取决于所处理资产的大小和类型以及演绎版的数量。 目标性能示例如下:
  • 使用标准再现时,小于1280x1280像素的图像会低于10秒
  • 对于使用标准再现的小于100 MB的图像,低于一分钟
  • 短于1分钟的高清视频剪辑低于5分钟
3. 下载速度 从AEM DAM下载时,吞吐量问题是,在浏览DAM管理员或DAM查找器时,缩略图不会立即显示。
吞吐量性能以下载速率衡量:千位/秒。 典型目标性能为300千位/秒,用于100个并发下载。
4. 影响资产处理性能的因素
为了能够评估处理资产所需的硬件,需要考虑以下方面:
  • 图像的分辨率(以像素为单位)
  • 分配给AEM进程的堆
图像中包含的像素数量决定了处理时间——更多像素意味着处理需要更长的时间。 图像类型、压缩率或存储图像的文件的相关大小不会影响总体性能。
堆已被确定为最重要的限制因素。 当资产超过可用的可用空闲内存时,处理性能会迅速下降。
DAM过程非常适合大规模并行执行。 在批处理和多核处理器中上传资产可加快每个资产的绝对花费时间。
5. 评估执行资产处理的硬件要求
对数字资产的广泛处理需要优化硬件资源,最相关的因素是图像大小和处理后图像的峰值吞吐量。
分配至少16GB堆并配置 DAM更新资产工作流程 ,以使用 支持使用Camera Raw处理图像 Camera Raw包获取原始图像。

了解系统

典型的DAM设置由通过负载平衡器访问DAM的最终用户组成。 DAM实例可能是群集设置的一部分,其中每个DAM实例在物理机器或虚拟机上的Java虚拟机进程中运行。 DAM存储由RAID磁盘在单机设置时提供,在群集设置时由受管网络附加存储提供。
以下图例介绍了一些解决方案(视情况而定)可能存在的性能缺陷区域。
与最终用户的网络连接 :网络连接缓慢可能会导致吞吐量问题,在某些情况下,延迟问题也会出现。 有时,用户与ISP的连接速度很慢,特别是在内部网中。 这表示网络拓扑不正确。
临时文件系统 :缓慢的本地文件系统可能会导致交互性能问题,尤其是在搜索时,因为搜索索引存储在本地磁盘上。 如果使用命令行进程,还会导致资产处理问题。
AEM DAM Finder Interactive性能问题(在搜索中经常遇到)是由于同一实例上的许多并发用户或其他消耗CPU的进程导致的CPU利用率高所致。 从虚拟机移动到专用计算机并确保计算机上没有其他服务运行有助于改进性能。 如果由于资产处理和许多并发用户导致CPU负载高,则Day建议添加其他群集节点。
AEM DAM Workflow Asset Ingestion期间长时间运行的工作流进程会导致资产处理性能问题。 根据所处理资产的类型,这可能表示CPU过度使用。 Day建议您减少系统上运行的其他进程数,并通过添加群集节点增加可用CPU数。
NAS连接性 —与NAS的网络连接性差会导致交互性能问题,因为在资产处理过程中访问新节点的速度因网络延迟而减慢。 此外,网络吞吐量缓慢会对吞吐量产生不利影响,但也会对资产处理性能产生不利影响,因为加载和保存再现的速度会减慢。
NAS中延迟和吞吐量不佳的原因通常是网络拓扑或NAS被其他服务过度利用。
网络附加存储 -过度使用网络附加存储系统可能会导致以下问题:
  • 磁盘空间不足是通过正确调整DAM项目大小而避免的常见问题。
  • 对于CRX,高磁盘延迟将传播到较慢的访问时间,并可能导致交互性能问题。
  • 磁盘吞吐量低可能导致CQ5 DAM的性能低。

性能测试

对于每个DAM项目,请务必建立一个性能测试制度,以快速识别和解决瓶颈。 为此,请考虑以下检查点:
  1. 使用JMeter进行端到端性能测试——模拟一个搜索和浏览会话示例以检测交互式性能问题。
  2. 使用JMeter的吞吐量和延迟测试——在客户端计算机上运行可确保不存在拓扑相关问题。
  3. 标准化的资产处理测试——摄取少量示例资产并衡量时间。 这应包括外部工作流集成。
  4. 监视每个群集节点的CPU、磁盘和内存使用情况。
  5. CRX读/写性能诊断以识别非处理相关问题。
  6. 监控网络延迟和从DAM群集到NAS的吞吐量。
  7. 如果可能,直接在NAS上测试读写性能以及磁盘延迟。

调整瓶颈

到目前为止,在项目中已使用以下性能调整:
  • 选择性再现生成:只通过向资产处理工作流中添加条件来生成所需的演绎版,这样,成本更高的演绎版只会为选定资产生成。
  • 实例之间共享数据存储:当磁盘空间不足时,这可以大幅降低所需的磁盘空间量,而代价是配置工作量增加,并丢失对数据存储的自动清理。