性能优化

关键问题是网站响应访客请求所用的时间。 尽管该值因每个请求而异，但可以定义平均目标值。 一旦证明这个值是可实现的和可维护的，它就可用于监控网站的性能并指示潜在问题的发展。

您针对的响应时间在创作环境和发布环境中是不同的，反映了目标受众的不同特征：

创作环境

输入和更新内容的作者将使用此环境。 它必须满足少数用户在更新内容页面和这些页面上的单个元素时各自生成大量性能密集型请求的需求。

发布环境

此环境包含可供用户使用的内容。 在这里，请求的数量甚至更多，速度也同样重要。 但由于请求的动态性较低，因此可以应用其他性能增强机制；例如缓存内容或负载平衡。

性能优化方法

AEM项目的性能优化方法可以归纳为五个简单的规则，您可以遵循这些规则以从一开始就避免性能问题：

1. 规划优化
2. 模拟现实
3. 制定明确的目标
4. 保持相关
5. 敏捷迭代周期

这些规则通常适用于Web项目，并与项目经理和系统管理员相关，以确保他们的项目在启动时不会面临性能挑战。

规划优化

为性能优化阶段规划大约10%的项目工作量。 实际性能优化要求取决于项目的复杂程度以及开发团队的经验。 虽然您的项目可能（最终）不需要分配时间，但最好始终在建议的区域规划性能优化。

如有可能，项目应首先面向有限受众软启动，以收集现实生活体验并执行进一步优化，而不会在完整发布后产生额外压力。

“实时”后，性能优化仍未结束。 现在，您会在系统上体验“真正的”负载。 在启动后计划进行其他调整很重要。

由于系统负载发生变化且系统性能配置文件会随时间变化，因此应按6-12个月的时间间隔安排性能“调准”或“运行状况检查”。

模拟现实

如果您使用网站上线，然后在启动后发现您遇到了性能问题，则可能是因为您的负载和性能测试没有充分模拟现实。

模拟现实很困难，您想要投入多少精力实现“真实”取决于项目的性质。 “真实”不仅表示“真实代码”和“真实流量”，还表示“真实内容”，尤其是关于内容大小和结构。 根据存储库的大小和结构，模板的行为可能会有所不同。

制定明确的目标

正确确定业绩目标的重要性不容低估。 通常，在人们专注于特定的绩效目标后，很难在事后改变这些目标，即使这些目标基于假设。

确立良好而稳健的业绩目标确实是最困难的领域之一。 通常最好从类似网站（例如新网站的前身）收集真实日志和基准。

保持相关

一次优化一个瓶颈是很重要的。 如果您尝试并行执行一些操作而没有验证一次优化的影响，则可能无法跟踪哪个优化措施发挥了作用。

敏捷迭代周期

性能调整是一个迭代过程，包括测量、分析、优化和验证，直到达到目标。 为此，在优化阶段实施敏捷验证过程，而不是在每次迭代后实施更重的测试过程。

此焦点意味着实施优化的开发人员应该可以快速判断优化是否已实现目标。 此信息很有价值，因为当达到目标时，优化即告结束。

基本性能准则

一般而言，将未缓存的html请求保留在100毫秒内。 更具体地说，以下内容可作为指导：

• 70%的页面请求应在100毫秒内得到响应。
• 25%的页面请求应在100毫秒 — 300毫秒内获得响应。
• 4%的页面请求应在300毫秒 — 500毫秒内获得响应。
• 1%的页面请求应在500毫秒 — 1000毫秒内获得响应。
• 任何页面的响应速度都不应小于1秒。

上述数字假定满足以下条件：

• 在发布时测量（无与创作环境相关的管理费用）
• 在服务器上测量（无网络开销）
• 未缓存(无AEM输出缓存，无Dispatcher缓存)
• 仅适用于具有许多依赖关系的复杂项目(HTML、JS、PDF…)
• 系统上没有其他负载

有一些问题经常会导致性能问题，其中包括：

• Dispatcher缓存效率低下
• 在一般显示模板中使用查询。

JVM和OS级别调整通常不会导致性能显着提升，因此应在优化周期的最后阶段执行。

内容存储库的结构方式也会影响性能。 为获得最佳性能，附加到内容存储库中单个节点的子节点数量不应超过1,000（作为一项规则）。

在常规的性能优化练习中，您最好的朋友包括：

• 不为目标组件考虑 request.log
• 基于组件的计时
• Java™探查器。

加载和编辑数字资产时的性能

由于加载和编辑数字资产时涉及大量数据，因此性能可能会成为一个问题。

这里有两个因素会影响性能：

• CPU — 多核可在转码时使工作更流畅
• 硬盘 — 并行RAID磁盘可实现相同性能

要提高性能，请考虑以下事项：

• 每天将上传多少资产？ 一个好的估计可以基于：

• 进行编辑的时间范围（通常为工作日的长度，对国际业务更合适）。
• 已上传图像的平均大小（以及每个图像生成的演绎版的大小）（以MB为单位）。
• 确定平均数据速率：

• 所有编辑中的80%是在20%的时间内完成的，因此在高峰期，您的平均数据速率是四倍。 这样的表现是你的目标。

性能监控

性能（或缺缺性能）是用户首先注意到的事项之一，因此对于任何具有用户界面的应用程序而言，性能至关重要。 要优化AEM安装的性能，请监视实例的各种属性及其行为。

有关如何执行性能监视的信息，请参见 监控性能.

导致性能问题的问题通常难以跟踪，即使其影响显而易见。

一个基本出发点是对系统正常工作时的良好了解。 除非您知道环境在正确执行时“外观”和“行为”如何，否则当性能下降时，很难找到问题。 花时间调查您的系统是否运行顺畅，并确保收集性能信息是一项持续的工作。 这样做可以为性能下降时的比较提供基础。

下图说明了请求AEM内容可以采用的路径，以及可能影响性能的不同元素数量。

性能也是卷与容量之间的平衡：

• 音量 — 系统处理和交付的输出量。
• 容量 — 系统传送卷的能力。

可以在整个Web链的不同位置展示性能。

影响性能的原因通常包括以下几个功能领域：

• 缓存
• 应用程序（您的项目）代码
• 搜索功能

有关性能的基本规则

在优化性能时，应牢记以下特定规则：

• 性能调整 必须 成为每个项目的一部分。
• 不要在开发周期早期进行优化。
• 性能的好坏取决于最薄弱的链接。
• 始终考虑容量与数量。
• 首先优化重要内容。
• 从不优化 逼真 目标。

配置性能

可以配置AEM的某些方面（和/或底层存储库）以优化性能。 以下是一些可能性和建议，在进行更改之前，您必须确定是否（或如何）使用相关功能。

搜索索引

从AEM 6.0开始，Adobe Experience Manager使用基于Oak的存储库架构。

您可以在此处找到更新的索引信息：

• 有关查询和索引的最佳实践
• 查询和索引

并发工作流处理

要提高性能，请限制同时运行的工作流进程的数量。 默认情况下，工作流引擎并行处理的工作流数量与Java™ VM可用的处理器数量相同。 当工作流步骤需要大量处理资源（RAM或CPU）时，并行运行多个这些工作流可能会对可用的服务器资源提出很高的要求。

例如，在上传图像（或常规DAM资产）时，工作流会自动将图像导入DAM。 图像通常具有高分辨率，可以轻松占用数百MB的栈进行处理。 并行处理这些图像会给内存子系统和垃圾收集器带来高负载。

工作流引擎使用Apache Sling作业队列来处理和计划工作项处理。 默认情况下，已从Apache Sling作业队列配置服务工厂创建以下作业队列服务，用于处理工作流作业：

• Granite工作流队列：大多数工作流步骤（如处理DAM资产的步骤）使用Granite工作流队列服务。
• Granite工作流外部进程作业队列：此服务用于特殊外部工作流步骤，通常用于联系外部系统和轮询结果。 例如，“InDesign媒体提取流程”步骤作为外部流程实施。 工作流引擎使用外部队列处理轮询。 (请参阅 com.day.cq.workflow.exec.WorkflowExternalProcess.)

配置这些服务以限制并发运行的工作流进程的最大数量。

存储库中的配置

如果您正在配置服务 使用sling：OsgiConfig节点中，必须找到现有服务的PID，例如：org.apache.sling.event.jobs.QueueConfiguration.370aad73-d01b-4a0b-abe4-20198d85f705。 您可以使用Web控制台发现PID。

配置名为的属性 queue.maxparallel.

Web控制台中的配置

配置这些服务 使用Web控制台，找到Apache Sling作业队列配置服务工厂下的现有配置项目。

配置名为Maximum Parallel Jobs的属性。

为特定工作流配置队列

为特定工作流模型创建作业队列，以便为该工作流模型配置作业处理。 这样，您的配置就会影响特定工作流的处理，而默认Granite工作流队列的配置将控制其他工作流的处理。

执行工作流模型时，它们会为特定主题创建Sling作业。 默认情况下，主题与为常规Granite工作流队列或Granite工作流外部进程作业队列配置的主题匹配：

• com/adobe/granite/workflow/job*
• com/adobe/granite/workflow/external/job*

工作流模型生成的实际作业主题包括特定于模型的后缀。 例如， DAM更新资产 工作流模型使用以下主题生成作业：

com/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/model

因此，可以为与工作流模型的作业主题相匹配的主题创建作业队列。 配置队列的性能相关属性只会影响生成与队列主题匹配的作业的工作流模型。

以下过程使用为工作流创建作业队列 DAM更新资产 以工作流为例。

1. 执行要为其创建作业队列的工作流模型，以便生成主题统计信息。 例如，将图像添加到资产以执行 DAM更新资产 工作流。

2. 打开Sling作业控制台(https://<host>:<port>/system/console/slingevent)。

3. 在控制台中了解与工作流相关的主题。 对于DAM更新资产，可找到以下主题：

   • com/adobe/granite/workflow/external/job/etc/workflow/models/dam/update_asset/jcr_content/model
   • com/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/model
   • com/adobe/granite/workflow/job/etc/workflow/models/dam-xmp-writeback/jcr_content/model

4. 为每个主题创建一个作业队列。 要创建作业队列，请为Apache Sling作业队列工厂服务创建工厂配置。

   工厂配置类似于中所述的Granite工作流队列 并发工作流处理，但Topics属性与工作流作业的主题相匹配。

AEM DAM资产同步服务

此 AssetSynchronizationService 用于同步已装载的存储库(包括LiveLink、Documentum®等)中的资产。 默认情况下，此同步每300秒（5分钟）进行一次常规检查，因此，如果您不使用已装载的存储库，则可以禁用此服务。

禁用服务操作由 配置OSGi服务 CQ DAM资产同步服务 以设置 同步周期 ( scheduler.period)到（最少）一年（以秒为单位）。

多个DAM实例

部署多个DAM实例可帮助提高性能，例如：

• 由于为创作环境定期上传许多资产，因此您的负载较高；此处有一个单独的DAM实例专门用于为创作提供服务。
• 您在全球各地拥有多个团队（例如，美国、欧洲、亚洲）。

其他注意事项包括：

• 将作者的“进行中的工作”与发布上的“最终工作”区分开
• 将内部作者用户与外部访客/发布用户区分开（例如，代理、新闻代表、客户和学生）。

质量保证最佳实践

性能对于您的发布环境至关重要。 因此，在实施项目时，您必须仔细规划和分析为发布环境进行的性能测试。

本节旨在以标准化方式概述定义测试概念时遇到的问题，专门针对您电脑上的性能测试， 发布 环境。 QA工程师、项目经理和系统管理员主要关注此信息。

AEM以下内容介绍了在EMC的 Publish 环境。 此性能测试涉及以下五个阶段：

• 知识验证
• 范围的定义
• 测试方法
• 绩效目标的定义
• 优化

控制是一个额外的、包含所有内容的过程 — 它是必要的，但不限于测试。

知识验证

第一步是记录开始测试之前必须了解的基本信息：

• 测试环境的架构
• 详细说明需要测试（单独和组合）的内部元素的应用程序映射

测试架构

记录用于性能测试的测试环境的架构。

您需要复制计划的生产发布环境，以及Dispatcher和负载平衡器。

应用程序映射

获取一个清晰的概述，从中可以创建整个应用程序的映射（您可能已在创作环境的测试中拥有此映射）。

应用程序的内部元素的图表示形式，可以概述测试要求；通过颜色编码，它还可以用作报告的基础。

范围定义

应用程序通常有多种使用案例。 有些用例很重要，有些则不那么重要。

为了将性能测试的范围集中到发布上，Adobe建议您定义以下内容：

• 最重要的业务用例
• 最关键的技术用例

用例的数量取决于您，但应将其限制为易于管理的数量（例如，5到10之间）。

选择关键用例后，可以为每个用例定义关键绩效指标(KPI)和用于衡量它们的工具。 常见KPI的示例包括：

• 端到端响应时间
• Servlet响应时间
• 单个组件的响应时间
• 服务的响应时间
• 线程池中的空闲线程数
• 可用连接数
• 系统资源，如CPU和I/O访问

测试方法

此概念包含四个用于定义和测试性能目标的场景：

• 单组件测试
• 组合组件测试
• 上线 方案
• 错误方案

基于以下原则

组件断点

• 每个组件在与性能相关时都有一个特定的断点。 也就是说，组件可以显示出良好性能，直到达到特定点，之后性能迅速下降。
• 要获取应用程序的完整概述，您必须首先验证组件，以确定何时达到每个组件的断点。
• 要查找可以执行负载测试的断点，您可以在一段时间内增加用户数量以创建不断增加的负载。 通过监控此负载和组件的响应，您会在组件到达断点时遇到特定的性能行为。 可以通过每秒并发事务数以及并发用户数（如果组件对此KPI敏感）来限定该点。
• 然后，此信息可作为改进基准，指示所用措施的效率，并帮助定义测试场景。

交易

• 术语事务用于表示完整网页的请求，包括页面本身和所有后续调用。 即页面请求、任何AJAX调用、图像和其他对象 请求深入分析.
• 要全面分析每个请求，可以表示调用栈栈的每个元素，然后合计每个请求的平均处理时间。

定义绩效目标

定义范围和相关KPI后，将设置特定的性能目标。 此过程包括设计测试场景和目标值。

在平均和峰值两种情况下测试性能。 此外，您还需要进行上线情景测试，以确保在网站首次发布时能够满足日益增长的对网站的兴趣需求。

您可能从现有网站收集的任何经验或统计信息也可用于确定未来的目标。 例如，来自实时网站的热门流量。

单组件测试

必须在平均和峰值条件下测试关键组件。

在这两种情况下，当预定义数量的用户使用系统时，您可以定义每秒的预期事务处理数。

组件	测试类型	否. 用户（共个）	Tx/秒（预期）	Tx/秒（已测试）	描述
主页单个用户	平均	1	1
	峰值	1	3
主页100个用户	平均	100	3
	峰值	100	3

组合组件测试

组合测试组件可更细致地反映应用程序行为。 必须再次测试平均值和峰值条件。

方案	组件	否. 用户（共个）	Tx/秒（预期）	Tx/秒（已测试）	描述
混合平均值	主页	10	1
	搜索	10	1
	新闻	10	2
	事件	10	1
	激活	10	3		作者行为的模拟。
混合峰	主页	100	5
	搜索	50	5
	新闻	100	10
	事件	100	10
	激活	20	20		作者行为的模拟。

上线测试

在网站发布后的前几天，您可能会更感兴趣。 此方案甚至大于您正在测试的峰值。 Adobe建议您测试上线场景，以确保系统可以适应这种情况。

方案	测试类型	否. 用户（共个）	Tx/秒（预期）	Tx/秒（已测试）	描述
启用峰值	主页	200	20
	搜索	100	10
	新闻	200	20
	事件	200	20
	激活	20	20		作者行为的模拟。

错误场景测试

测试错误情况以确保系统正确且正确地反应。 不仅在错误本身的处理方式上，而且可能在性能上产生影响。 例如：

• 当用户尝试在搜索框中输入无效的搜索词时会发生什么情况
• 如果搜索词过于宽泛，以至于返回的结果数量过多，会出现什么情况

在设计这些测试时，应该记住，并非所有情景都会定期发生。 但是，它们对整个系统的影响非常重要。

错误方案	错误类型	否. 用户（共个）	Tx/秒（预期）	Tx/秒（已测试）	描述
搜索组件过载	搜索全局通配符（星号）	10	1		只搜索&ast；&ast；&ast；。
	停用词	20	2		搜索停用词。
	空字符串	10	1		正在搜索空字符串。
	特殊字符	10	1		正在搜索特殊字符。

耐力测试

只有在系统连续运行（小时或天）后，才会遇到某些问题。 持久性测试用于测试所需时间段内的恒定平均负载。 然后可以分析任何性能下降。

方案	测试类型	否. 用户（共个）	Tx/秒（预期）	Tx/秒（已测试）	描述
耐力测试（72小时）	主页	10	1
	搜索	10	1
	新闻	20	2
	事件	10	1
	激活	1	3		作者行为的模拟。

优化

在实施的后期，优化应用程序以实现和最大化性能目标。

必须对所做的任何优化进行测试，以确保它们具有：

• 未影响功能
• 已在释放前通过负载测试验证

提供了一系列工具来帮助您进行负载生成、性能监控和结果分析。 其中一些工具包括：

• JMet
• 加载运行程序
• 红外线
• Java™交互式配置文件

优化后，再次测试以确认影响。

报告

持续报告使每个人都能及时了解状态。 如前面在颜色编码中提到的，体系结构图可用于此状态。

完成所有测试后，报告以下内容：

• 遇到任何严重错误
• 仍需要更多调查的非关键问题
• 测试期间所做的任何假设
• 测试中提出的任何建议

使用Dispatcher时优化性能

此 调度程序 是Adobe的缓存和/或负载平衡工具。 使用Dispatcher时，请考虑优化网站缓存性能。

Dispatcher提供了多种内置机制，如果您的网站利用这些机制可以优化性能。 此部分介绍了如何设计您的网站以最大限度地提高缓存优势。

计算Dispatcher缓存比率

缓存比率公式估算缓存处理的请求占进入系统的请求总数的百分比。 要计算缓存比率，您需要以下各项：

• 请求总数。 此信息可在Apache中获取 access.log. 欲知更多详情，请参见 Apache官方文档.

• 发布实例服务的请求数。 此信息可在 request.log 实例的。 有关更多详细信息，请参阅 解释request.log 和 查找日志文件.

计算缓存比的公式为：

• (请求总数 减号 Publish上的请求数) 划分 按请求总数。

例如，如果请求总数为129491，并且发布实例提供的请求数58959为，则缓存比率为： (129491 - 58959)/129491= 54.5%.

如果您没有一对一的发布者/Dispatcher配对，请将所有Dispatcher和发布者的请求添加到一起以获得准确的测量。 另请参阅 建议的部署.

使用一致的页面编码

使用Dispatcher版本4.1.11，您可以缓存响应标头。 如果不在Dispatcher上缓存响应标头，则在标头中存储页面编码信息时，可能会出现问题。 在此情况下，当 Dispatcher 从缓存中提供一个页面时，Web 服务器的默认编码将用于该页面。可通过两种方式避免此问题：

• 如果您只使用一种编码，请确保 Web 服务器上使用的编码与 AEM 网站的默认编码相同。
• 要设置编码，请使用 <META> 标签中HTML head 部分，如以下示例所示：

        <META http-equiv="Content-Type" content="text/html; charset=EUC-JP">

消除 URL 参数

如果可能，请消除要缓存的页面的 URL 参数。例如，如果您有一个图片库，则绝不会缓存以下 URL（除非对 Dispatcher 进行相应配置）：

www.myCompany.com/pictures/gallery.html?event=christmas&page=1

不过，您可以将这些参数放入页面 URL 中，如下所示：

www.myCompany.com/pictures/gallery.christmas.1.html

按 URL 进行自定义

如果您允许用户更改字体大小（或任何其他版面自定义设置），请确保各种自定义设置都反映在 URL 中。

例如，由于不会缓存 cookie，因此如果您将字体大小存储在 cookie（或类似机制）中，则不会为缓存的页面保留字体大小。因此，Dispatcher 会随机返回任意字体大小的文档。

在 URL 中包含字体大小作为选择器可避免出现此问题：

www.myCompany.com/news/main.large.html

使用作标题的图像文件失效

如果您将页面标题或其他文本渲染为图片，建议您存储文件，以便在更新页面内容时将其删除：

1. 将图像文件放入与页面相同的文件夹中。

2. 对图像文件使用以下命名格式：

   <page file name>.<image file name>

例如，您可以存储页面的标题 myPage.html 在 file myPage.title.gif. 由于此文件会在页面更新时自动被删除，因此对页面标题进行的任何更改都会自动反映在缓存中。

使用于导航的图像文件失效

如果将图片用于导航条目，则方法基本上与标题相同，但稍微复杂一些。 将所有导航图像与目标页面一起存储。如果将两张图片用于一般或活动场景，则可以使用以下脚本：

• 一个正常显示页面的脚本。
• 一个处理“.normal”请求并返回正常图片的脚本。
• 一个处理“.active”请求并返回活动图片的脚本。

请务必使用与页面相同的命名句柄创建这些图片，以确保内容更新会删除这些图片和页面。

对于未修改的页面，图片将保留在缓存中，尽管页面本身会自动失效。

个性化

建议您将个性化限制在必要的地方。 原因如下：

• 如果您使用可随意自定义的开始页面，则用户每次请求该页面时都必须对它进行编辑。
• 相反，如果您提供了10个不同的起始页供您选择，则可以缓存其中的每个起始页，从而提高性能。

如果您通过将用户名放入标题栏来个性化每个页面（例如），则会影响性能。

关于将限制内容和公共内容混合到一个页面上，请考虑以下策略：在Dispatcher中使用服务器端包含，或在浏览器中通过Ajax使用客户端包含。

粘性连接

粘性连接可确保同一个用户的文档全部在同一服务器上撰写。如果用户在退出此文件夹不久后返回，则此连接仍保持粘性。要保存所有需要网站的粘性连接的文档，请定义一个文件夹。 尽量不要在该文件夹中放入其他文件。如果您使用个性化的页面和会话数据，此方案将影响负载平衡。

MIME 类型

浏览器可通过两种方式确定文件的类型：

1. 通过其扩展(例如， .html， .gif、和 .jpg)。
2. 按服务器随文件一起发送的 MIME 类型。

对于大多数文件，MIME 类型隐含在文件扩展名中。那就是，

1. 通过其扩展(例如， .html， .gif、和 .jpg)。
2. 按服务器随文件一起发送的 MIME 类型。

如果文件名没有扩展名，则以纯文本形式显示。

使用Dispatcher版本4.1.11，您可以缓存响应标头。 如果不在Dispatcher上缓存响应标头，则MIME类型是HTTP标头的一部分。 因此，如果您的AEM应用程序返回的文件没有可识别的文件结尾，而是依赖MIME类型，则这些文件可能会显示不正确。

要确保正确缓存文件，请遵循以下准则：

• 确保文件始终具有正确的扩展名。
• 避免使用通用文件服务脚本，这些脚本的URL包括 download.jsp?file=2214. 要使用包含文件规范的URL，请重写脚本。 对于上一个示例，此重写是 download.2214.pdf.

备份性能

本节介绍一系列用于评估AEM备份性能和备份活动对应用程序性能影响的基准。 AEM备份在运行时会对系统造成很大的负载，Adobe会测量这种影响，以及尝试调节这些影响的备份延迟设置的影响。 目的是提供有关备份在真实配置和大量生产数据中的预期性能的一些参考数据，并就如何估计计划系统的备份时间提供指导。

参考环境

物理系统

本文档中报告的结果是从在参考环境中运行的基准测试中获得的，该环境具有以下配置。 此配置类似于数据中心中的典型生产环境：

• HP ProLiant DL380 G6,8个CPU x 2.533 GHz
• 串行连接SCSI 300 GB，10,000-RPM驱动器
• 硬件RAID控制器；RAID0+5阵列中的八个驱动器
• VMware映像CPU x 2 Intel Xeon® E5540,2.53 GHz
• Red Hat® Linux® 2.6.18-194.el5；Java™ 1.6.0_29
• 单个作者实例

此服务器上的磁盘子系统速度很快，代表可用于生产服务器的高性能RAID配置。 备份性能对磁盘性能非常敏感，而且此环境中的结果反映了快速RAID配置的性能。 VMWare映像配置为在RAID阵列上有一个物理驻留在本地磁盘存储中的大型磁盘卷。

AEM配置将存储库和数据存储区与操作系统和AEM软件放在同一逻辑卷上。 备份的目标目录也驻留在此逻辑文件系统上。

数据卷

下表说明了备份基准测试中使用的数据卷的大小。 首先安装初始基线内容，然后添加其他已知数量的数据以增加备份内容的大小。 以特定的增量创建备份，以表示内容的大幅增加以及一天内可能会产生的内容。 内容（页面、图像、标记）的分发大致基于真实的生产资产组合。 页面、图像和标记最多只能包含800个子页面。 每个页面都包含标题、Flash、文本/图像、视频、幻灯片放映、表单、表格、云和轮盘组件。 图像从包含400个唯一文件（大小从37 KB到594 KB）的池上传。

内容	节点	页面	图像	标记
基本安装	69 610	562	256	237
用于增量备份的小内容		+100	+2	+2
用于完整备份的大型内容		+10 000	+100	+100

重复备份基准，每次重复时添加其他内容集。

基准方案

备份基准包括两种主要情况：在系统处于重大应用程序负载时进行备份，以及在系统空闲时进行备份。 虽然一般建议在AEM尽可能空闲时执行备份，但在某些情况下，系统负载不足时必须运行备份。

• 空闲状态 — 在AEM上执行备份时，不执行其他活动。
• 负载不足 — 在系统负载低于在线进程的80%时执行备份。 备份延迟可变，以查看对负载的影响。

从AEM服务器日志中获取备份时间和结果备份的大小。 通常建议将备份安排在AEM空闲时（例如午夜）的关闭时间。 此方案代表了推荐的方法。

加载由创建的页面、删除的页面、遍历和查询组成，其中大多数加载来自页面遍历和查询。 添加和删除太多页面会不断增加工作区的大小，并阻止备份完成。 脚本使用的负载分布是75%的页面遍历、24%的查询和1%的页面创建（单级别不含嵌套子页面）。 空闲系统上的每秒平均事务峰值通过四个并发线程实现，该线程用于在负载下测试备份。

负载对备份性能的影响可以通过有此应用程序负载和无此应用程序负载时的性能差异来估算。 通过比较每小时事务处理量的方案吞吐量，可以发现备份对应用程序吞吐量的影响，其中事务处理量包括进行中的并发备份和不进行中的并发备份，以及备份以不同的“备份延迟”设置运行。

• 延迟设置 — 对于几种情况，备份延迟设置也有所变化，使用10毫秒（默认）、1毫秒和0毫秒的值来探索此设置如何影响备份性能。
• 备份类型 — 所有备份都是存储库的外部备份，这些备份在不创建zip文件的情况下备份到备份目录，但有一种情况除外，这种情况下比较直接使用tar命令。 由于无法将增量备份创建到zip文件，或者当以前的完整备份是zip文件时，备份目录方法最常用于生产环境。

结果摘要

备份时间和吞吐量

这些基准测试的主要结果是显示备份时间随备份类型和整体数据量的变化而如何变化。 下图显示了使用默认备份配置获得的备份时间，该时间是总页数的函数。

空闲实例上的备份时间相当一致，平均每秒0.608 MB，不考虑完整备份或增量备份（见下图）。 备份时间只是要备份的数据量的函数。 完成完整备份的时间会随着总页数而明显增加。 完成增量备份的时间也会随着总页数而增加，但速度要低得多。 由于备份的数据量相对较少，完成增量备份所需的时间要短得多。

生成的备份大小是完成备份所花费时间的主要决定因素。 下图显示了作为最终备份大小的函数所花费的时间。

此图表说明了增量备份和完全备份都遵循简单的大小与时间模式，Adobe可以将其测量为吞吐量。 空闲实例上的备份时间相当一致，平均每秒0.61 MB，无论基准环境上的完整或增量备份如何。

备份延迟

提供备份延迟参数以限制备份可能干扰生产工作负载的程度。 参数指定等待时间（以毫秒为单位），该等待时间会逐个文件地散播到备份操作中。 总体效果部分取决于受影响的文件大小。 以MB/秒为单位测量备份性能为比较延迟对备份的影响提供了一种合理的方法。

• 在常规应用程序负载的同时运行备份，会对常规负载的吞吐量产生负面影响。
• 影响可能很小（仅为5%）或显着，导致吞吐量下降多达75%。 这很可能主要取决于应用程序。
• 备份不是CPU上的重负载，因此，与I/O密集型工作负载相比，备份对CPU密集型生产工作负载的影响较小。

相比之下，使用文件系统备份(“tar”)备份相同的存储库文件获得的吞吐量。 tar的性能相当，但略高于延迟设置为零的备份。 即使设置一个较小的延迟，也会大大降低备份吞吐量，而默认延迟10毫秒会导致吞吐量大大降低。 在可能安排在应用程序总体使用率较低或应用程序可能空闲时进行备份的情况下，将延迟降低到默认值以下，以允许更快速地执行备份。

进行中的备份对应用程序吞吐量的实际影响取决于应用程序和基础架构的详细信息。 延迟值的选择应通过对应用程序的经验分析来确定，但应尽量选择较小的值，以便能够尽快完成备份。 由于延迟值的选择与应用程序吞吐量影响之间只有弱相关性，因此延迟的选择应有利于缩短整体备份时间，以最大限度地减少备份带来的整体影响。 如果备份需要8小时才能完成，但吞吐量影响为–20% ，则总体影响可能比完成备份需要2小时，但吞吐量影响为–30%的备份更大。

引用

• 管理 — 备份和恢复
• 管理 — 容量和卷