硬件大小调整指南 hardware-sizing-guidelines

CAUTION
AEM 6.4已结束扩展支持,本文档将不再更新。 有关更多详细信息,请参阅 技术支助期. 查找支持的版本 此处.

这些大小调整指南提供了部署AEM项目所需的硬件资源的近似值。 规模估算取决于项目的架构、解决方案的复杂性、预期流量和项目要求。 本指南可帮助您确定特定解决方案的硬件需求,或查找硬件需求的较高和较低估计值。

需要考虑的基本因素有:

  • 网络速度

    • 网络延迟
    • 可用带宽
  • 计算速度

    • 缓存效率
    • 预期流量
    • 模板、应用程序和组件的复杂性
    • 并发作者
    • 创作操作的复杂性(简单的内容编辑、MSM转出等)
  • I/O性能

    • 文件或数据库存储的性能和效率
  • 硬盘

    • 存储库大小至少是存储库大小的2或3倍
  • 内存

    • 网站的大小(内容对象、页面和用户的数量)
    • 同时处于活动状态的用户/会话数

架构 architecture

典型的AEM设置由创作和发布环境组成。 这些环境对底层硬件大小和系统配置有不同的要求。 有关这两个环境的详细注意事项,请参见 创作环境发布环境 中。

在典型的项目设置中,您有多个要在其中存放项目阶段的环境:

  • 开发环境
    开发新功能或进行重大更改。 最佳做法是为每个开发人员使用开发环境(通常是其个人系统上的本地安装)。

  • 创作测试环境
    验证更改。 测试环境的数量可能因项目要求而异(例如,QA、集成测试或用户验收测试各不相同)。

  • 发布测试环境
    主要用于测试社交协作用例和/或作者与多个发布实例之间的交互。

  • 创作生产环境
    供作者编辑内容。

  • 发布生产环境
    用于提供已发布的内容。

此外,环境可能有所不同,从运行AEM和应用程序服务器的单服务器系统到一组高度缩放的多服务器、多CPU群集实例。 我们建议您为每个生产系统使用单独的计算机,并且不要在这些计算机上运行其他应用程序。

一般硬件大小调整注意事项 generic-hardware-sizing-considerations

以下各节提供了有关如何计算硬件需求的指南,其中考虑了各种因素。 对于大型系统,我们建议您对引用配置执行一组简单的内部基准测试。

性能优化是一项基本任务,需要在对特定项目进行任何基准测试之前执行。 请确保应用 性能优化文档 在执行任何基准测试并将其结果用于任何硬件大小计算之前。

高级用例的硬件大小调整要求需要基于项目的详细性能评估。 需要特殊硬件资源的高级用例的特点包括:

  • 高内容负载/吞吐量
  • 大量使用自定义代码、自定义工作流或第三方软件库
  • 与不支持的外部系统集成

磁盘空间/硬盘 disk-space-hard-drive

所需的磁盘空间在很大程度上取决于Web应用程序的卷和类型。 计算时应考虑:

  • 页面、资产和其他存储库存储的实体(如工作流、用户档案等)的数量和大小。
  • 估计的内容更改频率,从而创建内容版本
  • 将生成的DAM资产演绎版的数量
  • 随着时间推移内容的总体增长

在“联机”和“脱机”修订清理期间持续监视磁盘空间。 如果可用磁盘空间降至临界值以下,则该过程将被取消。 关键值是存储库当前磁盘占用量的25%,且不可配置。 建议将磁盘大小至少比存储库大小(包括估计的增长)大2或3倍。

考虑为数据冗余设置独立磁盘冗余阵列(RAID,如RAID10)。

NOTE
生产实例的临时目录应至少具有6 GB的可用空间。

虚拟化 virtualization

AEM在虚拟化环境中运行良好,但可能存在CPU或I/O等无法直接与物理硬件相等的因素。 建议选择更高的I/O速度(通常),因为这在大多数情况下都是关键因素。 要准确了解需要哪些资源,必须对环境进行基准测试。

AEM实例的并行化 parallelization-of-aem-instances

失败安全 fail-safeness

在至少两个单独的系统上部署故障安全网站。 如果一个系统出现故障,另一个系统就可以接管并补偿系统故障。

系统资源可扩展性 system-resources-scalability

当所有系统都运行时,可以提高计算性能。 这种附加性能不一定与群集节点的数量成线性关系,因为这种关系高度依赖于技术环境;请参见 群集文档 以了解更多信息。

根据特定Web项目的基本要求和具体用例,估算需要多少个群集节点:

  • 从失败安全性的角度,有必要根据群集节点恢复所花费的时长,确定所有环境的关键故障的严重程度和故障补偿时间。
  • 在可扩展性方面,写操作的数量基本上是最重要的因素;请参阅 并行工作的作者 (对于创作环境和 社交协作 ,以访问发布环境。 可以为仅访问系统以处理读取操作的操作建立负载平衡;请参阅 Dispatcher 以了解详细信息。

创作环境特定的计算 author-environment-specific-calculations

为了进行基准测试,Adobe为独立创作实例开发了一些基准测试。

  • 基准测试1

    计算加载配置文件的最大吞吐量,其中用户在基本加载300个具有相似性质的现有页面的基础上执行简单的创建页面练习。 涉及的步骤包括登录到网站,创建包含SWF和图像/文本的页面,添加标签云,然后激活页面。

    • 结果

      发现上述简单页面创建练习(视为一次交易)的最大吞吐量为1730次交易/小时。

  • 基准测试2

    当加载配置文件混合了以下几类内容时,计算最大吞吐量:创建新页面(10%)、修改现有页面(80%)和创建页面,然后连续修改页面(10%)。 页面的复杂性与基准测试1的配置文件中的复杂性相同。 可通过添加图像和修改文本内容来对页面进行基本修改。 同样,此练习是在基准测试1中定义的300页复杂度的基础加载基础上执行的。

    • 结果

      发现这种混合操作方案的最大吞吐量为每小时3252个事务。

NOTE
吞吐率不区分加载配置文件中的事务类型。 用于测量吞吐量的方法确保在工作负载中包含每种类型事务的固定比例。

上述两项测试清楚地表明,吞吐量会因操作类型而异。 将您环境中的活动用作调整系统大小的基础。 通过修改等较少的操作(这种操作也比较常见),您将获得更好的吞吐量。

缓存 caching

在创作环境中,缓存效率通常要低得多,因为网站更改更频繁,内容也是高度交互和个性化的。 使用调度程序,您可以缓存AEM库、JavaScripts、CSS文件和布局图像。 这可以加快创作过程的某些方面。 将Web服务器配置为额外设置标头,以便在这些资源上进行浏览器缓存,将减少HTTP请求的数量,从而改善作者体验到的系统响应性。

并行工作的作者 authors-working-in-parallel

在创作环境中,并行工作的作者数量及其交互添加到系统中的负载是主要限制因素。 因此,我们建议您根据数据的共享吞吐量来扩展系统。

对于此类情景,Adobe在创作实例的两个不共享的节点群集上执行基准测试。

  • 基准测试1a

    使用包含2个创作实例的活动 — 活动 — 无共享群集,使用加载配置文件计算最大吞吐量,在该配置文件中,用户在基本加载300个现有页面(所有均具有相似性质)的基础上执行简单的创建页面练习。

    • 结果

      在诸如上面的简单页面创建练习(视为一次交易)中,最大吞吐量为2016次交易/小时。 与同一基准测试的独立创作实例相比,这大约增加了16%。

  • 基准测试2b

    使用由2个创作实例构成的活动 — 活动 — 无共享集群,当加载配置文件具有新页面创建(10%)、现有页面修改(80%)以及连续页面创建和修改(10%)的混合时,计算最大吞吐量。 页面的复杂性与基准测试1的配置文件中的复杂性相同。 可通过添加图像和修改文本内容来对页面进行基本修改。 同样,此练习是在基本加载的300页复杂度基础上执行的,这与基准测试1中定义的相同。

    • 结果

      发现这种混合操作方案的最大吞吐量为6288个事务/小时。 与同一基准测试的独立创作实例相比,这大约增加了93%。

NOTE
吞吐率不区分加载配置文件中的事务类型。 用于测量吞吐量的方法确保在工作负载中包含每种类型事务的固定比例。

上述两个测试清楚地强调,AEM可以很好地针对正在使用AEM执行基本编辑操作的作者进行缩放。 通常,AEM在缩放读取操作方面最有效。

在典型的网站上,大多数创作都发生在项目阶段。 网站上线后,并行工作的作者数量通常会下降到较低(操作模式)的平均值。

您可以按如下方式计算创作环境所需的计算机(或CPU)数:

n = numberOfParallelAuthors / 30

当作者使用AEM执行基本操作时,此公式可用作缩放CPU的一般准则。 假定系统和应用程序已优化。 但是,对于MSM或Assets等高级功能,公式将不为true(请参阅以下部分)。

另请参阅 并行化性能优化.

硬件Recommendations hardware-recommendations

通常,您可以在创作环境中使用与发布环境建议相同的硬件。 通常,创作系统中的网站流量要低得多,但缓存效率也较低。 但是,这里的基本因素是并行工作的作者数量,以及对系统所执行的操作类型。 通常,AEM群集(创作环境的)在缩放读取操作方面最有效;换句话说,AEM群集可以很好地与正在执行基本编辑操作的作者一起扩展。

Adobe的基准测试是使用RedHat 5.5操作系统执行的,该操作系统在Hewlett-Packard ProLiant DL380 G5硬件平台上运行,且配置如下:

  • 两个3.00GHz四核英特尔至强X5450 CPU
  • 8 GB RAM
  • Broadcom NetXtreme II BCM5708千兆位以太网
  • HP智能阵列RAID控制器,256 MB高速缓存
  • 两个146 GB 10,000 RPM SAS磁盘,配置为RAID0条带集
  • SPEC CINT2006费率基准得分为110

AEM实例运行的堆大小最小为256M,堆大小最大为1024M。

发布环境特定的计算 publish-environment-specific-calculations

缓存效率和流量 caching-efficiency-and-traffic

缓存效率对于网站速度至关重要。 下表显示优化的AEM系统使用反向代理(如调度程序)可以每秒处理多少页:

缓存比率
页数(峰值)
百万页/日(平均)
100%
1000-2000
35-70
99%
910
32
95%
690
25
90%
520
18
60%
220
8
0%
100
3.5
CAUTION
免责声明:这些数字基于默认的硬件配置,并且可能因所使用的特定硬件而异。

缓存比率是调度程序无需访问AEM即可返回的页面百分比。 100%表示调度程序回答所有请求,0%表示AEM计算每个页面。

模板和应用程序的复杂性 complexity-of-templates-and-applications

如果您使用复杂模板,则AEM需要更多时间来渲染页面。 从缓存中提取的页面不会受到此影响,但在考虑整体响应时间时,页面大小仍与此相关。 渲染复杂页面可能比渲染简单页面轻松花费十倍的时间。

公式 formula

使用以下公式,您可以计算对AEM解决方案整体复杂性的估计:

complexity = applicationComplexity + ((1-cacheRatio) * templateComplexity)

根据复杂性,您可以确定发布环境所需的服务器(或CPU核心)数量,如下所示:

n = (traffic * complexity / 1000 ) * activations

公式中的变量如下:

流量
每秒的预期峰值流量。 您可以将其估计为每日页面点击量除以35’00。
applicationComplexy

对于简单应用程序,使用1;对于复杂应用程序,使用2;或中间值:

  • 1 — 完全匿名的面向内容的网站
  • 1.1 — 一个具有客户端/Target个性化功能的完全匿名内容网站
  • 1.5 — 一个面向内容的网站,其中包含匿名和登录部分,客户端/Target个性化
  • 1.7 — 适用于同时具有匿名和已登录部分的内容网站、客户端/Target个性化以及一些用户生成的内容
  • 2 — 整个网站需要登录的地方,可广泛使用用户生成的内容和各种个性化技术
cacheRatio
调度程序缓存中传出的页面的百分比。 如果所有页面都来自缓存,则使用1;如果每个页面都由AEM计算,则使用0。
templateComplexy
使用1到10之间的值表示模板的复杂性。 数字越大,表示模板越复杂,每页平均包含10个组件的网站使用值1,页面平均包含40个组件的网站使用值5,平均包含100个组件的网站使用值1。
激活
每小时平均激活次数(将平均大小的页面和资产从创作层复制到发布层)除以x ,其中x是在系统上完成的激活次数,对系统处理的其他任务没有性能方面的影响。 您还可以预定义悲观的初始值,如x = 100。

如果您的网站更复杂,则还需要更强大的Web服务器,以便AEM能够在可接受的时间内响应请求。

  • 复杂性低于4:

    • 1024 MB JVM RAM&Ast;
    • 中低性能CPU
  • 复杂性介于4到8之间:

    • 2048 MB JVM RAM&Ast;
    • 中高性能CPU
  • 复杂性超过8:

    • 4096 MB JVM RAM&Ast;
    • 高到高端性能的CPU
NOTE
*除了JVM所需的内存之外,还为操作系统保留足够的RAM。

其他特定用例的计算 additional-use-case-specific-calculations

除了计算默认Web应用程序之外,您还可能需要考虑以下用例的特定因素。 计算值将添加到默认计算中。

特定于资产的注意事项 assets-specific-considerations

数字资产的广泛处理需要优化的硬件资源,最相关的因素是图像大小和处理图像的峰值吞吐量。

分配至少16GB的堆,并配置DAM更新资产工作流以使用 Camera Raw包 用于摄取原始图像。

NOTE
图像的较高吞吐量意味着计算资源需要能够与系统I/O保持同步,反之亦然。 例如,如果通过导入图像来启动工作流,则通过WebDAV上传许多图像可能会导致工作流积压。
对TarPM、数据存储和搜索索引使用单独的磁盘有助于优化系统I/O行为(但是,通常将搜索索引保留在本地是有意义的)。
NOTE
另请参阅 Assets性能指南.

多站点管理器 multi-site-manager

在创作环境中使用AEM MSM时,资源消耗量主要取决于特定用例。 基本因素包括:

  • Live-Copy的数量
  • 推广的周期
  • 要转出的内容树大小
  • 转出操作的连接功能

使用具有代表性的内容摘录测试计划的用例可以帮助您更好地了解资源使用情况。 如果使用计划吞吐量外推结果,则可以评估AEM MSM所需的额外资源。

此外,还请考虑,如果AEM MSM用例消耗的资源比计划消耗的资源多,则并行工作的作者将会察觉到性能副作用。

AEM Communities大小调整注意事项 aem-communities-sizing-considerations

包含AEM Communities功能的AEM站点(社区站点)在发布环境中会体验到站点访客(成员)的高级别交互。

社区站点的大小调整注意事项取决于社区成员预期的交互情况以及页面内容的最佳性能是否具有更高的重要性。

用户生成的内容(UGC)提交的成员与页面内容分开存储。 虽然AEM平台使用从创作到发布的节点存储来复制站点内容,但AEM Communities却对从未复制的UGC使用单个通用存储。

对于UGC存储,需要选择一个存储资源提供程序(SRP),这会影响所选的部署。
请参阅

recommendation-more-help
d284b6a8-dae4-4549-aa9e-2b09317eb02a