性能优化 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和OS级别的调整通常不会导致性能的大幅提升，因此应在优化周期的最后阶段执行。

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

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

加载和编辑Digital Assets时的性能 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作业队列配置服务工厂下找到现有配置项。

配置名为Maximum Parallel Jobs的属性。

为特定工作流配置队列 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)设置为（最少）一年（以秒为单位定义）。

多个DAM实例 multiple-dam-instances

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

其他注意事项包括：

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

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

本节旨在对定义测试概念时遇到的一些问题进行标准化概述，这些测试概念专门用于​ publish ​环境中的性能测试。 此信息主要与QA工程师、项目经理和系统管理员有关。

下面介绍在​ Publish ​环境中对AEM应用程序进行性能测试的标准化方法。 该性能测试包括以下五个阶段：

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

知识验证 verification-of-knowledge

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

测试架构 test-architecture

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

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

应用程序映射 application-map

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

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

范围定义 scope-definition

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

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

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

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

测试方法 test-methodologies

此概念有四种用于定义和测试性能目标的场景：

基于以下原则

组件断点 component-breakpoints

交易 transactions

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

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

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

从现有网站收集的任何经验或统计数据也可能在确定未来目标时非常有用。 例如，实时网站中的热门流量。

单组件测试 single-component-tests

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

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

组合组件测试 combined-component-tests

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

上线测试 going-live-tests

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

错误方案测试 error-scenario-tests

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

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

耐用测试 endurance-tests

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

优化 optimization

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

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

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

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

报告 reporting

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

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

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

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

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

计算Dispatcher缓存比率 calculating-the-dispatcher-cache-ratio

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

计算缓存比的公式为：

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

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

使用一致的页面编码 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的标题存储在file 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备份在系统运行时给系统带来很大的负载，Adobe会测量这种影响，以及尝试调节这些影响的备份延迟设置的影响。 目的是提供一些参考数据，说明备份在实际配置中的预期性能和生产数据量，并指导如何估计计划系统的备份时间。

参考环境 reference-environment

物理系统 physical-system

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

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

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

数据卷 data-volumes

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

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

设定方案基准 benchmark-scenarios

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

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

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

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

结果摘要 summary-of-results

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

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

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

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

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

备份延迟 backup-delay

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

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

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

引用 references