Assets 大小调整指南 assets-sizing-guide

调整环境大小时 Adobe Experience Manager Assets 实现,确保磁盘、CPU、内存、IO和网络吞吐量方面有足够的可用资源非常重要。 调整其中许多资源的大小需要了解有多少资源正在加载到系统中。 如果没有更好的量度,您可以将现有库的大小除以库的存留期,以找出创建资产的速率。

磁盘 disk

数据存储 datastore

调整所需的磁盘空间大小时出现的一个常见错误 Assets 实施是根据要摄取到系统中的原始图像的大小进行计算。 默认情况下, Experience Manager 除了原始图像之外,还创建三个演绎版以用于渲染 Experience Manager 用户界面元素。 在以前的实施中,已观察到这些演绎版假定的资源大小是摄取资源大小的两倍。

除了开箱即用的呈现版本之外,大多数用户还会定义自定义呈现版本。 除了演绎版, Assets 允许您从常见文件类型中提取子资产,例如 Adobe InDesign 和 Adobe Illustrator.

最后,的版本控制功能 Experience Manager 在版本历史记录中存储资产的重复项。 您可以配置要经常清除的版本。 但是,许多用户选择将版本保留在系统中很长时间,这会占用额外的存储空间。

考虑到这些因素,您需要一种方法来计算存储用户资产所需的存储空间,此存储空间精确到可以接受的程度。

  1. 确定加载到系统中的资源的大小和数量。
  2. 获取要上传到的资源的代表性示例 Experience Manager. 例如,如果您计划将PSD、JPG、AI和PDF文件加载到系统中,则需要每种文件格式的多个示例图像。 此外,这些示例应该能够代表不同的文件大小和图像的复杂性。
  3. 定义要使用的演绎版。
  4. 在中创建节目 Experience Manager 使用 ImageMagick 或 Adobe Creative Cloud 应用程序。 除了用户指定的呈现版本之外,还应创建现成的呈现版本。 对于实施Dynamic Media的用户,可以使用IC二进制文件生成要存储在Experience Manager中的PTIFF演绎版。
  5. 如果您计划使用子资产,请为相应的文件类型生成它们。
  6. 比较输出图像、演绎版和子资源与原始图像的大小。 它允许您在系统加载时生成预期的增长因子。 例如,如果在处理1 GB的资源后生成大小合计为3 GB的演绎版和子资源,则演绎版增长因子为3。
  7. 确定在系统中维护资源版本的最长时间。
  8. 确定在系统中修改现有资产的频率。 如果 Experience Manager 用作创意工作流的协作中心,更改量很大。 如果仅将完成的资产上传到系统,则此数字会低得多。
  9. 确定每月加载到系统中的资产数量。 如果您不确定,请确定当前可用的资产数量,然后将该数量除以最早资产的年限来计算大约数量。

执行上述步骤可帮助您确定以下内容:

  • 要加载的资源的原始大小。
  • 要加载的资源数。
  • 演绎版增长因子。
  • 每月修改的资源的数量。
  • 维护资产版本的月数。
  • 每月加载的新资源数。
  • 存储空间分配的多年增长。

您可以在网络大小调整电子表格中指定这些数字,以确定数据存储所需的总空间。 此外,它还是确定在中维护资产版本或修改资产的影响的有用工具 Experience Manager 磁盘增长。

该工具中填充的示例数据说明了执行上述步骤的重要性。 如果您仅根据正在加载的原始图像调整数据存储的大小(1 TB),则可能会将存储库大小低估了15倍。

获取文件

共享数据存储 shared-datastores

对于大型数据存储,您可以通过网络连接驱动器上的共享文件数据存储或通过Amazon S3数据存储来实施共享数据存储。 在这种情况下,各个实例不需要维护二进制文件的副本。 此外,共享数据存储有助于进行无二进制复制,并帮助减少用于将资产复制到发布环境的带宽。

用例 use-cases

数据存储可以在主实例和备用创作实例之间共享,以最大限度地减少在主实例中进行更改以更新备用实例所需的时间。 您还可以在创作实例和发布实例之间共享数据存储,以最大程度地减少复制期间的流量。

缺点 drawbacks

由于存在一些隐患,并非在所有情况下都建议共享数据存储。

单点故障 single-point-of-failure

拥有共享数据存储,会给基础架构带来单点故障。 假设您的系统有一个作者实例和两个发布实例,每个实例都有自己的数据存储。 如果其中任何一个崩溃,其他两个仍可以继续运行。 但是,如果数据存储是共享的,则单个磁盘故障可能会使整个基础架构停止运行。 因此,请确保维护共享数据存储的备份,以便从中快速恢复数据存储。

建议将AWS S3服务部署到共享数据存储,因为与常规磁盘体系结构相比,它可以显着降低故障概率。

增加复杂性 increased-complexity

共享数据存储也会增加操作的复杂性,例如垃圾收集。 通常,只需单击一下即可启动独立数据存储的垃圾收集。 但是,共享数据存储除了在单个节点上运行实际集合之外,还需要对使用该数据存储的每个成员进行标记整理操作。

对于AWS操作,实施单个中心位置(通过Amazon S3)而不是构建EBS卷的RAID阵列,可以显着抵消系统的复杂性和操作风险。

性能问题 performance-concerns

共享数据存储要求将二进制文件存储在网络装载的驱动器上,该驱动器在所有实例之间共享。 由于这些二进制文件通过网络进行访问,因此会对系统性能产生负面影响。 使用到快速磁盘阵列的快速网络连接可以部分缓解影响。 然而,这是一个代价高昂的提议。 如果存在AWS操作,则所有磁盘都是远程磁盘,需要网络连接。 临时卷在实例启动或停止时丢失数据。

延迟 latency

S3实施中的延迟由后台写入线程引入。 备份过程必须考虑这种延迟。 此外,在进行备份时,Lucene索引可能会保持不完整。 它适用于任何写入S3数据存储并从其他实例访问的时间敏感文件。

节点存储或文档存储 node-store-document-store

由于以下资源消耗,很难获得NodeStore或DocumentStore的精确大小数字:

  • 资源元数据
  • 资源版本
  • 审核日志
  • 存档和活动工作流

由于二进制文件存储在数据存储中,因此每个二进制文件都会占用一些空间。 大多数存储库的大小低于100 GB。 但是,可能有更大的存储库,其大小最多为1 TB。 此外,要执行离线压缩,卷上需要足够的可用空间,以便与预压缩版本一起重写压缩的存储库。 一个好的经验法则是将磁盘的大小设置为存储库预期大小的1.5倍。

对于存储库,使用IOPS级别大于3000的SSD或磁盘。 为了消除IOPS引入性能瓶颈的可能性,请监控CPU IO等待级别以发现问题的早期迹象。

获取文件

网络 network

Assets 有几个使用案例使网络性能比我们的许多产品更重要 Experience Manager 项目。 客户可以拥有快速服务器,但如果网络连接不够大,不足以支持从系统上传和下载资产的用户的负载,则服务器速度仍会显得缓慢。 有一种很有效的方法来确定用户与的网络连接中的阻塞点 Experience Manager 在 用户体验、实例大小调整、工作流评估和网络拓扑的资源注意事项.

限制 limitations

在调整实施规模时,请务必牢记系统限制。 如果建议的实施超出这些限制,则采用创意策略,例如跨多个分区资产 Assets 实施。

文件大小不是导致内存不足(OOM)问题的唯一因素。 它还取决于图像的尺寸。 通过在启动时提供更大的栈大小可避免OOM问题 Experience Manager.

此外,您还可以编辑的阈值大小属性 com.day.cq.dam.commons.handler.StandardImageHandler 组件来使用大于零的中间临时文件。

最大资源数 maximum-number-of-assets

由于文件系统限制,数据存储中可以存在的文件数限制可能为21亿。 存储库可能会在达到数据存储限制之前很长时间由于节点过多而遇到问题。

如果格式副本的生成不正确,请使用Camera Raw的库。 但是,在这种情况下,图像的最长边不应大于65000像素。 此外,图像不应包含超过512 MP (512 x 1024 x 1024像素)。 资产规模并不重要。

很难准确估计使用的特定栈支持的现成TIFF文件的大小 Experience Manager 因为其他因素(如像素大小)会影响处理。 有可能 Experience Manager 可以立即处理大小为255 MB的文件,但不能处理大小为18 MB的文件,因为后者的像素数异常高于前者。

资源大小 size-of-assets

默认情况下, Experience Manager 允许您上传文件大小最大为2 GB的资产。 在中上传非常大的资产 Experience Manager,请参见 用于上传超大资产的配置.

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2