Assets大小调整指南 assets-sizing-guide
在调整Adobe Experience Manager Assets实施的环境大小时，必须确保有足够的可用资源，如磁盘、CPU、内存、IO和网络吞吐量。 调整其中许多资源的大小需要了解有多少资源正在加载到系统中。 如果没有更好的量度，您可以将现有库的大小除以库的存留期，以找出创建资产的速率。
磁盘 disk
数据存储 datastore
在调整Assets实施的所需磁盘空间时经常会犯一个错误，即计算时基于要摄取到系统中的原始映像的大小。 默认情况下，Experience Manager除了原始图像之外，还将创建三个演绎版，以用于演绎版Experience Manager用户界面元素。 在以前的实施中，已观察到这些演绎版假定的资源大小是摄取资源大小的两倍。
除了开箱即用的呈现版本之外，大多数用户还会定义自定义呈现版本。 除了演绎版之外，Assets还允许您从常见文件类型（如Adobe InDesign和Adobe Illustrator）中提取子资产。
最后，Experience Manager的版本控制功能会在版本历史记录中存储资源的重复项。 您可以配置要经常清除的版本。 但是，许多用户选择将版本保留在系统中很长时间，这会占用额外的存储空间。
考虑到这些因素，您需要一种方法来计算存储用户资产所需的存储空间，此存储空间精确到可以接受的程度。
- 确定加载到系统中的资源的大小和数量。
- 获取要上传到Experience Manager中的具有代表性的资源示例。 例如，如果您计划将PSD、JPG、AI和PDF文件加载到系统中，则需要每种文件格式的多个示例图像。 此外，这些示例应该能够代表不同的文件大小和图像的复杂性。
- 定义要使用的演绎版。
- 使用ImageMagick或Adobe Creative Cloud应用程序在Experience Manager中创建演绎版。 除了用户指定的呈现版本之外，还应创建现成的呈现版本。 对于实施Dynamic Media的用户，可以使用IC二进制文件生成要存储在Experience Manager中的PTIFF演绎版。
- 如果您计划使用子资产，请为相应的文件类型生成它们。
- 比较输出图像、演绎版和子资源与原始图像的大小。 它允许您在系统加载时生成预期的增长因子。 例如，如果在处理1 GB的资源后生成大小合计为3 GB的演绎版和子资源，则演绎版增长因子为3。
- 确定在系统中维护资源版本的最长时间。
- 确定在系统中修改现有资产的频率。 如果将Experience Manager用作创意工作流的协作中心，则更改量会很大。 如果仅将完成的资产上传到系统，则此数字会低得多。
- 确定每月加载到系统中的资产数量。 如果您不确定，请确定当前可用的资产数量，然后将该数量除以最早资产的年限来计算大约数量。
执行上述步骤可帮助您确定以下内容：
- 要加载的资源的原始大小。
- 要加载的资源数。
- 演绎版增长因子。
- 每月修改的资源的数量。
- 维护资产版本的月数。
- 每月加载的新资源数。
- 存储空间分配的多年增长。
您可以在网络大小调整电子表格中指定这些数字，以确定数据存储所需的总空间。 此外，它还是确定在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的网络连接中，在Assets考虑用户体验、实例大小调整、工作流评估和网络拓扑时，有一个确定阻塞点的好方法。
限制 limitations
在调整实施规模时，请务必牢记系统限制。 如果建议的实施超出这些限制，则采用创意策略，例如跨多个Assets实施对资产进行分区。
文件大小不是导致内存不足(OOM)问题的唯一因素。 它还取决于图像的尺寸。 启动Experience Manager时，通过提供更大的栈大小可避免OOM问题。
此外，您还可以在Configuration Manager中编辑com.day.cq.dam.commons.handler.StandardImageHandler组件的阈值大小属性以使用大于零的中间临时文件。
最大资源数 maximum-number-of-assets
由于文件系统限制，数据存储中可以存在的文件数限制可能为21亿。 存储库可能会在达到数据存储限制之前很长时间由于节点过多而遇到问题。
如果格式副本的生成不正确，请使用Camera Raw库。 但是，在这种情况下，图像的最长边不应大于65000像素。 此外，图像不应包含超过512 MP （512 x 1024 x 1024像素）。 资产规模并不重要。
由于其他因素（如像素大小）会影响处理，因此很难准确地估计使用特定栈为Experience Manager现成支持的TIFF文件的大小。 Experience Manager可以处理现成255 MB的文件，但无法处理18 MB的文件，因为后者包含的像素数异常高于前者。
资源大小 size-of-assets
默认情况下，Experience Manager允许您上传文件大小最大为2 GB的资产。 要在Experience Manager中上传非常大的资产，请参阅配置以上传非常大的资产。