性能优化 performance-optimization

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

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

创作环境 author-environment

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

发布环境 publish-environment

此环境包含可供用户使用的内容。 在这里，请求数量更多，速度也同样重要，但由于请求的性质不那么动态，因此可以应用额外的性能提升机制；例如缓存内容或负载平衡。

性能优化方法 performance-optimization-methodology

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

这些规则在很大程度上适用于Web项目，并且与项目经理和系统管理员相关，可确保其项目在启动时不会面临性能挑战。

优化计划 planning-for-optimization

在性能优化阶段，应计划大约10%的项目工作。 当然，实际的性能优化要求将取决于项目的复杂性级别和开发团队的经验。 虽然您的项目可能（最终）不需要所有分配的时间，但最好始终在建议的区域中规划性能优化。

在可能的情况下，首先应向有限的受众软启动项目，以收集实际体验并进一步优化，而无需在发布完整公告后承受额外压力。

“实时”后，性能优化就不会结束。 这是您在系统上体验到“实际”负载的时间点。 在启动后计划进一步调整很重要。

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

模拟现实 simulate-reality

如果您通过网站上线并在启动后发现遇到性能问题，则只有一个原因：您的负载和性能测试没有足够地模拟现实。

模拟现实是困难的，而您在获得“真实”方面有多大的投入，取决于您项目的性质。 “真实”不仅表示“真实代码”和“真实流量”，还表示“真实内容”，尤其是有关内容大小和结构的内容。 请记住，您的模板可能会因存储库的大小和结构而有完全不同的行为。

确立坚实的目标 establish-solid-goals

正确制定业绩目标的重要性不容低估。 通常，一旦人们专注于具体的绩效目标，就很难在以后改变这些目标，即使这些目标是基于疯狂的假设。

建立良好、稳健的绩效目标确实是最棘手的领域之一。 通常最好从可比较的网站（例如新网站的前身）收集真实生活日志和基准。

保持相关性 stay-relevant

一次优化一个瓶颈很重要。 如果您尝试在不验证某个优化的影响的情况下并行执行某些操作，您将无法跟踪哪个优化措施实际上有帮助。

敏捷迭代周期 agile-iteration-cycles

性能调整是一个迭代过程，包括测量、分析、优化和验证，直到达到目标。 为了正确考虑这一方面，在优化阶段实施灵活的验证过程，而不是在每次迭代后执行更重的测试过程。

这在很大程度上意味着实施优化的开发人员应该能够快速判断优化是否已达到目标。 这是有价值的信息，因为当达到目标时，优化就会结束。

基本性能准则 basic-performance-guidelines

通常，将未缓存的html请求保留在100毫秒以下。 更具体地说，以下内容可能是准则：

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

有些问题经常导致性能问题。 这主要围绕：

JVM和操作系统级别的调整通常不会导致性能的大幅提升，因此应在优化周期的最后阶段执行。

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

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

加载和编辑数字资产时的性能 performance-when-loading-and-editing-digital-assets

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

以下两点会影响性能：

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

性能监控 performance-monitoring

性能（或者缺乏性能）是用户首先注意到的事情之一，因此，与任何具有用户界面的应用程序一样，性能至关重要。 要优化AEM安装的性能，您需要监控实例的各种属性及其行为。

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

导致性能问题的问题通常很难跟踪，即使它们的效果很容易看到。

基本起点是系统正常运行时对系统的良好了解。 除非您知道环境在正常运行时“外观”和“行为”如何，否则在性能恶化时，很难找到问题。 这意味着，在系统正常运行时，您应该花一些时间来调查系统，并确保收集性能信息是一项持续的任务。 这将为您提供在性能受到影响时进行比较的基础。

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

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

卷 系统处理和传送的输出量。

容量 系统传送卷的功能。

这可以在整个Web链的不同位置进行说明。

有几个功能领域通常负责影响性能：

性能基本规则 basic-rules-regarding-performance

在优化性能时，应牢记以下某些规则：

性能配置 configuring-for-performance

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

搜索索引 search-indexing

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

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

并发工作流处理 concurrent-workflow-processing

限制同时运行的工作流进程的数量以提高性能。 默认情况下，工作流引擎会并行处理任意数量的工作流，只要有可用于Java VM的处理器。 当工作流步骤需要大量处理资源（RAM或CPU）时，并行运行其中几个工作流可能会对可用的服务器资源提出很高要求。

例如，在上传图像（或通常为DAM资产）时，工作流会自动将图像导入DAM。 图像通常是高分辨率的，并且处理时容易消耗数百MB的堆。 并行处理这些图像会给存储子系统和垃圾收集器带来高负载。

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

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

注意： 配置这些作业队列会影响所有工作流，除非您为特定的工作流模型创建了作业队列(请参阅 为特定工作流模型配置队列 )。

存储库中的配置 configuration-in-the-repo

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

您需要配置名为 queue.maxparallel.

Web控制台中的配置 configuration-in-the-web-console

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

您需要配置名为“最大并行作业数”的属性。

为特定工作流配置队列 configure-the-queue-for-a-specific-workflow

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

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

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

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

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

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

AEM DAM资产同步服务 cq-dam-asset-synchronization-service

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

此操作由 配置OSGi服务 CQ DAM资产同步服务 设置 同步期 ( scheduler.period)至（最少为）1年（以秒为单位定义）。

多个DAM实例 multiple-dam-instances

例如，部署多个DAM实例有助于提高性能：

其他注意事项包括：

质量保证最佳实践 best-practices-for-quality-assurance

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

本节旨在对定义专门用于您的性能测试的测试概念所涉及的问题进行标准化概述 发布 环境。 这主要是QA工程师、项目经理和系统管理员感兴趣的。

下面介绍了对上的AEM应用程序进行性能测试的标准化方法 发布 环境。 这涉及以下5个阶段：

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

知识验证 verification-of-knowledge

第一步是记录在开始测试之前您需要了解的基本信息：

测试架构 test-architecture

您应该清楚地记录用于性能测试的测试环境的架构。

您需要复制计划的生产发布环境以及调度程序和负载平衡器。

应用程序图 application-map

要获得清晰的概述，您可以创建整个应用程序的映射（您很可能已在创作环境的测试中获得该映射）。

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

范围定义 scope-definition

应用程序通常会有一系列用例。 有些将非常重要，有些则不那么重要。

要将性能测试的范围集中在发布上，我们建议您定义：

用例的数量由您来决定，但应该限制为一个易于管理的数字（例如，在5到10之间）。

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

测试方法 test-methodologies

此概念有4种用于定义和测试性能目标的方案：

根据以下原则。

组件断点 component-breakpoints

交易 transactions

定义绩效目标 defining-the-performance-goals

定义范围和相关KPI后，可以设置特定的绩效目标。 这包括设计测试方案和目标值。

您需要在平均和峰值条件下测试性能。 此外，您还需要上线方案测试，以确保在网站首次可用时能够满足客户对网站日益浓厚的兴趣。

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

单个组件测试 single-component-tests

关键组件需要在平均和峰值条件下进行测试。

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

组合组件测试 combined-component-tests

通过组合测试组件，可以更深入地反映应用程序行为。 同样，必须测试平均和峰值条件。

上线测试 going-live-tests

在您的网站发布后的最初几天，您可能会有更高的兴趣级别。 这可能比您测试的峰值还要大。 强烈建议测试上线方案，以确保系统能够满足此情况。

错误方案测试 error-scenario-tests

还必须测试错误情景，以确保系统能正确、适当地反应。 不仅在于错误本身的处理方式，还在于它可能对性能的影响。 例如：

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

耐力测试 endurance-tests

系统连续运行一段时间后，才会遇到某些问题；不管是几个小时，甚至几天。 使用耐久性测试来测试在所需时间段内的恒定平均负载。 然后可以分析任何性能下降。

优化 optimization

在实施的后续阶段，您需要优化应用程序以实现/最大化性能目标。

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

有一系列工具可帮助您进行负载生成、性能监控和/或结果分析：

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

报告 reporting

需要持续报告，以便让每个人都了解情况。 如前面使用颜色编码时所述，架构图可用于此。

完成所有测试后，您将需要报告：

使用Dispatcher时优化性能 optimizing-performance-when-using-the-dispatcher

的 Dispatcher 是Adobe的缓存和/或负载平衡工具。 使用Dispatcher时，您应考虑优化网站以提高缓存性能。

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

计算调度程序缓存比率 calculating-the-dispatcher-cache-ratio

缓存比率公式估计缓存处理的请求在进入系统的请求总数中所占的百分比。 要计算缓存比率，您需要满足以下条件：

计算缓存比率的公式为：

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

如果您没有一对发布者/调度程序配对，则需要将所有调度程序和发布者的请求添加到一起，以获得准确的测量。 另请参阅 推荐的部署.

使用一致的页面编码 using-consistent-page-encoding

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

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

消除 URL 参数 avoid-url-parameters

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

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

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

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

按 URL 进行自定义 customize-by-url

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

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

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

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

使用作标题的图像文件失效 invalidating-image-files-used-as-titles

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

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

使用于导航的图像文件失效 invalidating-image-files-used-for-navigation

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

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

对于未修改的页面，图片仍保留在缓存中，但页面本身通常会自动失效。

个性化 personalization

建议您将个性化限制为必要时。 原因如下：

如果您个性化每个页面（例如，将用户名称置于标题栏中），则可能会对性能产生影响。

关于在一个页面上混合使用受限内容和公共内容，您可能需要考虑一种策略，该策略可利用Dispatcher中的服务器端包含，或者通过浏览器中的Ajax的客户端包含。

粘性连接 sticky-connections

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

MIME 类型 mime-types

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

对于大多数文件，MIME 类型隐含在文件扩展名中。即：

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

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

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

备份性能 backup-performance

本节介绍一系列用于评估AEM备份性能和备份活动对应用程序性能的影响的基准。 AEM备份在系统运行时会给系统带来很大的负载，我们会测量这一情况，以及尝试调制这些效果的备份延迟设置的影响。 其目标是提供一些参考数据，说明实际配置中备份的预期性能和生产数据的数量，并就如何估算计划系统的备份时间提供指导。

参考环境 reference-environment

物理系统 physical-system

本文档中报告的结果是从参考环境中运行的基准获得的，其配置如下。 此配置设计为类似于数据中心中的典型生产环境：

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

AEM配置将存储库和数据存储放在同一逻辑卷上，以及所有操作系统和AEM软件。 备份的目标目录也位于此逻辑文件系统上。

数据卷 data-volumes

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

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

基准方案 benchmark-scenarios

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

从AEM服务器日志获取备份时间和生成备份的大小。 通常建议在AEM空闲时（如在午夜）将备份安排为非时间备份。 这种情况代表了建议的方法。

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

负载对备份性能的影响可以通过此应用程序负载时和不时的性能差异来估计。 备份对应用程序吞吐量的影响可通过比较每小时事务中的方案吞吐量（包括和不包括持续的并发备份）和备份以不同的“备份延迟”设置运行时的情况吞吐量来发现。

结果摘要 summary-of-results

备份时间和吞吐量 backup-time-and-throughput

这些基准的主要结果是显示备份时间随备份类型和总数据量的变化情况。 下图显示了使用默认备份配置获得的备份时间，它是页总数的函数。

空闲实例上的备份时间相当一致，无论是完整备份还是增量备份，平均为0.608 MB/s（请参阅下图）。 备份时间只是备份数据量的函数。 完成完整备份的时间会随着页面总数的增加而明显增加。 完成增量备份的时间也会随着页面总数而增加，但速度要低得多。 由于备份的数据量相对较小，完成增量备份所花费的时间要短得多。

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

此图表说明，增量备份和完整备份都遵循一种简单的大小与时间模式，我们可以将此模式作为吞吐量进行衡量。 空闲实例上的备份时间相当一致，平均为0.61 MB/秒，而不考虑基准环境中的完整或增量备份。

备份延迟 backup-delay

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

为了比较使用文件系统备份（使用“tar”）备份同一存储库文件时获得的吞吐量。 tar的性能相当，但略高于将延迟设置为零的备份。 即使设置小的延迟也会大大降低备份吞吐量，而默认延迟为10毫秒会大大降低吞吐量。 如果在总体应用程序使用率很低或应用程序完全空闲时可能安排备份，则可能需要将延迟降低到默认值以下，以便允许备份更快地进行。

持续备份的应用程序吞吐量的实际影响取决于应用程序和基础架构的详细信息。 延迟值的选择应通过对应用程序的经验分析来完成，但应尽可能选择小的延迟值，以便能够尽快完成备份。 由于选择延迟值与对应用程序吞吐量的影响之间只存在微弱的关联，因此选择延迟应该有利于缩短总体备份时间，以最大限度地减少备份的整体影响。 备份需要8小时才能完成，但吞吐量影响为–20%的备份，其总体影响可能比完成需要2小时而吞吐量影响为–30%的备份大。

引用 references