监控和维护AEM实例

部署AEM实例后，将需要某些任务来监控和维护其操作、性能和完整性。

这里的一个关键因素是，要识别潜在问题，您需要知道系统在正常情况下的外观和行为。 最好通过监控系统并收集一段时间内的信息来实现这一点。

检查	注意事项	评论/操作
备份计划。		请参阅如何备份实例。
灾难恢复计划。	贵公司的灾难恢复准则。
错误跟踪系统可用于报告问题。	例如，bugzilla、jira或许多其他中的一个。
正在监控文件系统。	如果可用磁盘空间不足，CRX存储库将“冻结”。 当空间可用时，它将恢复。	可用空间变低时，日志文件中会显示“ *ERROR* LowDiskSpaceBlocker”消息。
正在 监控日志文件。
系统监视（持续）在后台运行。	包括CPU、内存、磁盘和网络使用情况。 例如，使用iostat / vmstat / perfmon。	记录的数据是可视化的，可用于跟踪性能问题。 也可以访问原始数据。
正在监控AEM性能。	包括请求计数器以监控流量级别。	如出现重大或长期业绩损失，应进行详细调查。
您正在监控复制代理。
定期清除工作流实例。	存储库大小和工作流性能。	请参阅定期清除工作流实例。

备份

备份以下内容是最佳做法：

• 您的软件安装 — 在对配置进行重大更改之前/之后
• 存储库中保存的内容 — 定期

贵公司可能会有一个备份策略，您需要遵循该策略，有关备份内容和备份时间的其他考虑事项包括：

• 系统和数据的重要性。
• 软件或数据发生更改的频率。
• 数据量；容量有时可能是问题，执行备份所需的时间也是问题。
• 用户在线时，是否可以进行备份；如果可能，性能会受到什么影响。
• 用户的地理分布；例如，何时是备份的最佳时间（以最大限度地减少影响）？
• 您的灾难恢复政策；有关必须存储备份数据的位置（例如站外、特定介质等）的准则。

通常，完整备份是定期进行（如每日、每周或每月），增量备份介于之间（如每小时、每天或每周）。

备份软件安装

安装后或对配置进行重大更改后，请备份软件安装。

为此，您需要备份整个存储库，然后：

1. 停止AEM。
2. 从文件系统备份整个<cq-installation-dir>。

备份存储库

CRX文档的备份和还原部分涵盖与CRX存储库备份相关的所有问题。

有关进行在线“热”备份的完整详细信息，请参阅创建在线备份。

版本清除

清除版本​工具用于清除存储库中节点或节点层次结构的版本。 其主要目的是通过删除节点的旧版本来帮助您减小存储库的大小。

本节介绍与AEM的版本控制功能相关的维护操作。 清除版本​工具用于清除存储库中节点或节点层次结构的版本。 其主要目的是通过删除节点的旧版本来帮助您减小存储库的大小。

概述

清除版本​工具🔗控制台​下的​版本控制​下提供了​清除版本工具，或直接从以下位置获取：

https://<server>:<port>/etc/versioning/purge.html

开始 路径必须完成清除的绝对路径。您可以通过单击存储库树导航器来选择开始路径。

​​递归清除数据时，您可以选择对一个节点执行操作，还是通过选择“递归”对整个层次结构执行操作。在最后一种情况下，给定路径定义层级的根节点。

要保留的 最大版本要保留的节点最大版本数。当这些数字超过此值时，将清除最早的版本。

最大版 本年龄节点版本的最大年龄。当版本的年龄超过此值时，会清除该值。

干式 运行由于删除内容的版本是确定的，并且在不恢复备份的情况下无法还原，因此清除版本工具提供了一种干式运行模式，允许您预览已清除的版本。要启动清除流程的干式运行，请单击“干式运行”。

​​清除启动对“开始路径”定义的节点上的版本的清除。

清除网站的版本

要清除网站的版本，请按如下步骤操作：

1. 导航到​工具控制台，选择​版本控制​并双击​清除版本。

2. 设置要清除的内容的开始路径(例如，/content/geometrixx-outdoors)。

   • 如果只想清除路径定义的节点，请取消选择​Recursive。
   • 如果要清除路径及其子代定义的节点，请选择​Recursive。

3. 设置要保留的最大版本数（针对每个节点）。 将留空，以不使用此设置。

4. 设置要保留的最大版本年龄（每个节点），以天为单位。 将留空，以不使用此设置。

5. 单击​干法运行​以预览清除过程将执行的操作。

6. 单击​清除​以启动该进程。

分析控制台

Dry Run​和​Purge​进程列出已处理的所有节点。 在此过程中，节点可能具有以下状态之一：

• ignore (not versionnable):该节点不支持版本控制，在过程中会忽略该节点。
• ignore (no version):该节点没有任何版本，在过程中会被忽略。
• retained:未清除该节点。
• purged:节点已清除。

此外，控制台还提供了有关这些版本的有用信息：

• V 1.0:版本号。
• V 1.0.1*星形指示版本为当前版本。
• Thu Mar 15 2012 08:37:32 GMT+0100:版本的日期。

在下一个示例中：

• 衬衫​版本因其版本年龄大于2天而被清除。
• 汤加时尚！ 版本会被清除，因为其版本数大于5。

使用审核记录和日志文件

与Adobe Experience Manager(AEM)相关的审核记录和日志文件可以在不同位置找到。 下面提供了您可以在何处查找内容的概述。

使用日志

AEM WCM记录详细日志。 在解包并启动快速入门后，您可以在中找到日志：

• <cq-installation-dir>/crx-quickstart/logs/
• <cq-installation-dir>/crx-quickstart/repository/

日志文件旋转

日志文件旋转是指通过定期创建新文件来限制文件增长的过程。 在AEM中，名为error.log的日志文件将根据给定规则每天旋转一次：

• 将根据模式{originalfilename} .yyyy-MM-dd重命名error.log文件。 例如，在2010年7月11日，当前日志文件被重命名为error.log-2010-07-10，然后创建新的error.og。
• 以前的日志文件不会被删除，因此您有责任定期清理旧的日志文件以限制磁盘的使用。

查找日志文件

安装了AEM的文件服务器上保存了各种日志文件：

• <cq-installation-dir>/crx-quickstart/logs

  • access.log

    此处注册了对AEM WCM和存储库的所有访问请求。

  • audit.log

    审核操作在此处注册。

  • error.log

    此处将注册错误消息（严重性级别不同）。

  • ImageServer-<PortId>-yyyy>-<mm>-<dd>.log

    仅当启用了Dynamic Media时，才使用此日志。 它提供用于分析内部ImageServer进程行为的统计和分析信息。

  • request.log

    每个访问请求都将随响应一起注册。

  • s7access-<yyyy>-<mm>-<dd>.log

    仅当启用了Dynamic Media时，才使用此日志。 s7access日志记录通过/is/image和/is/content向Dynamic Media发出的每个请求。

  • stderr.log

    保存在启动期间生成的、严重性级别不同的错误消息。 默认情况下，日志级别设置为Warning(WARN)

  • stdout.log

    保存指示启动期间事件的日志记录消息。

  • upgrade.log

    提供从com.day.compat.codeupgrade和com.adobe.cq.upgradesexecutor包运行的所有升级操作的日志。

• <cq-installation-dir>/crx-quickstart/repository

  • revision.log

    修订日志信息。

激活DEBUG日志级别

默认日志级别Apache Sling日志记录配置为“信息”，因此调试消息不会被记录。

要激活日志记录器的调试日志级别，请将属性org.apache.sling.commons.log.level设置为在存储库中进行调试。 例如，在/libs/sling/config/org.apache.sling.commons.log.LogManager上配置全局Apache Sling日志记录。

调试文件中的行通常以DEBUG开头，然后提供日志级别、安装程序操作和日志消息。 例如：

DEBUG 3 WebApp Panel: WebApp successfully deployed

日志级别如下：

0	致命错误	操作失败，安装程序无法继续。
1	错误	操作失败。 安装将继续，但部分AEM WCM未正确安装，无法正常工作。
2	警告	操作已成功，但遇到问题。 AEM WCM可能正常工作，也可能无法正常工作。
3	信息	操作成功。

创建自定义日志文件

在某些情况下，您可能希望创建具有不同日志级别的自定义日志文件。 您可以在存储库中通过以下方式执行此操作：

1. 如果尚未存在，请为项目/apps/<project-name>/config创建新的配置文件夹(sling:Folder)。

2. 在/apps/<project-name>/config下，为新的Apache Sling日志记录器配置创建节点：

   • 名称:

   org.apache.sling.commons.log.LogManager.factory.config-<identifier> （因为这是一个日志记录器）

   其中， <identifier>被替换为您（必须）输入以标识实例的自由文本（您不能忽略此信息）。 例如，org.apache.sling.commons.log.LogManager.factory.config-MINE

   • 类型: sling:OsgiConfig
   注意

   虽然不是技术要求，但建议将<identifier>设为唯一。

3. 在此节点上设置以下属性：

   • 名称: org.apache.sling.commons.log.file

     类型：字符串

     值：指定日志文件；例如，logs/myLogFile.log

   • 名称: org.apache.sling.commons.log.names

     类型: String[] (String + Multi)

     值：指定记录器要为其记录消息的OSGi服务；例如，以下所有内容：

     • org.apache.sling
     • org.apache.felix
     • com.day

   • 名称: org.apache.sling.commons.log.level

     类型：字符串

     值：指定所需的日志级别（debug、info、warn或error）；例如debug

   • 根据需要配置其他参数：

     • 名称: org.apache.sling.commons.log.pattern

       类型: String

       值：根据需要指定日志消息的模式；例如，

       {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}

   注意

   org.apache.sling.commons.log.pattern 最多支持六个参数。

   {0}类型java.util.Date的时间戳

   {1}日志标记

   {2}当前线程的名称

   {3}日志记录器的名称

   {4}日志级别

   {5}日志消息

   如果日志调用包含Throwable ，则堆栈跟踪会附加到消息中。

   注意

   org.apache.sling.commons.log.names必须具有值。

   注意

   日志写入程序路径与crx-quickstart位置相关。

   因此，指定为：

   logs/thelog.log

   写入：

   <cq-installation-dir>/crx-quickstart/logs/thelog.log。

   以及指定为：

   ../logs/thelog.log

   写入目录：

   <cq-installation-dir>/logs/
   （即<cq-installation-dir>/crx-quickstart/旁）

4. 只有在需要新写入程序时（即配置与默认写入程序不同时），才需要执行此步骤。

   注意

   只有当现有的默认值不合适时，才需要新的日志记录写入器配置。
   如果未配置显式写入器，则系统将根据默认值自动生成隐式写入器。

   在/apps/<project-name>/config下，为新的Apache Sling日志记录编写器配置创建一个节点：

   • 名称：org.apache.sling.commons.log.LogManager.factory.writer-<identifier>（因为这是Writer）

     与日志记录器一样， <identifier>被替换为您（必须）输入用来标识实例的自由文本（您不能忽略此信息）。 例如，org.apache.sling.commons.log.LogManager.factory.writer-MINE

   • 类型: sling:OsgiConfig

   注意

   虽然不是技术要求，但建议将<identifier>设为唯一。

   在此节点上设置以下属性：

   • 名称: org.apache.sling.commons.log.file

     类型: String

     值：指定日志文件，使其与日志记录器中指定的文件匹配；

     对于此示例， ../logs/myLogFile.log。

   • 根据需要配置其他参数：

     • 名称: org.apache.sling.commons.log.file.number

       类型: Long

       值：指定要保留的日志文件数；例如，5

     • 名称: org.apache.sling.commons.log.file.size

       类型: String

       值：按大小/日期指定控制文件旋转的所需条件；例如，'.'yyyy-MM-dd

   注意

   org.apache.sling.commons.log.file.size 通过设置以下任一项来控制日志文件的旋转：

   • 最大文件大小
   • 时间/日期计划

   以指示何时将创建新文件（以及根据名称模式重命名的现有文件）。

   • 可以使用数字指定大小限制。 如果未提供大小指示器，则将其视为字节数，或者可以添加大小指示器之一 — KB、 MB或GB（忽略大小写）。
   • 时间/日期计划可以指定为java.util.SimpleDateFormat模式。 这定义文件旋转的时间段；还附加到旋转文件的后缀（用于标识）。

   默认为 '.'yyyy-MM-dd（用于每日日志旋转）。

   例如，在2010年1月20日的午夜（或当发生此事件后的第一条日志消息更加准确时），…/logs/error.log将重命名为…/logs/error.log.2010-01-20。 1月21日的日志记录将输出到（新的空）…/logs/error.log ，直到在下一天的更改时对其进行滚动。

   '.'yyyy-MM	每月初的轮换
   '.'yyyy-ww	每周第一天轮转（取决于区域设置）。
   '.'yyyy-MM-dd	每天午夜轮调。
   '.'yyyy-MM-dd-a	每天午夜和中午轮流。
   '.'yyyy-MM-dd-HH	每小时的顶部旋转一次。
   '.'yyyy-MM-dd-HH-mm	每分钟开始轮转。

   注意：指定时间/日期时：

   1. 应该对单引号(“ ”)中的文本进行“转义”；

      这是为了避免某些字符被解释为模式字母。

   2. 在选项中的任意位置，只允许对有效文件名使用允许的字符。

5. 使用所选工具读取新的日志文件。

   此示例创建的日志文件将为../crx-quickstart/logs/myLogFile.log。

Felix控制台还在../system/console/slinglog提供了有关Sling日志支持的信息；例如http://localhost:4502/system/console/slinglog。

查找审核记录

保留审计记录，以提供谁执行了什么和何时执行的记录。 会为AEM WCM和OSGi事件生成不同的审核记录。

AEM在页面创作时显示的WCM审核记录

1. 打开页面。

2. 在Sidekick中，您可以选择带有锁定图标的选项卡，然后双击​审核日志……

3. 将打开一个新窗口，显示当前页面的审核记录列表。

   

4. 要关闭窗口时，单击​确定。

AEM WCM存储库中的审核记录

在/var/audit文件夹中，会根据资源保留审核记录。 您可以向下展开，直到您看到单个记录及其包含的信息为止。

这些条目包含的信息与编辑页面时显示的信息相同。

Web控制台中的OSGi审核记录

OSGi事件还会生成审核记录，这些记录可从AEM Web控制台的​配置状态​选项卡 — > 日志文件​选项卡中查看：

监视复制代理

您可以监视复制队列以检测队列何时关闭或被阻止 — 这反过来可能表示发布实例或外部系统有问题：

• 是否启用所有必需队列？

• 是否仍需要任何禁用的队列？

• 所有enabled队列应具有状态idle或active，这表示正常操作；队列不应为blocked，这通常表示接收方出现问题。

• 如果队列的大小随时间增长，这可能表示队列被阻止。

要监视复制代理，请执行以下操作：

1. 访问AEM中的​工具​选项卡。

2. 单击​复制。

3. 双击相应环境（左窗格或右窗格）的代理链接；例如，作者​上的代理。

   生成的窗口显示了创作环境的所有复制代理的概述，包括其目标和状态。

4. 单击相应的代理名称（即链接）可显示有关该代理的详细信息：

   

   在此对话框中，您可以：

   • 查看是否启用了代理。
   • 查看任何复制的目标。
   • 查看复制队列当前是否处于活动状态（已启用）。
   • 查看队列中是否有任何项目。
   • ​​刷新或 ​​清除以更新队列条目的显示；这有助于您查看进入队列和离开队列的项目。
   • 查 看日志以访问复制代理执行的任何操作的日志。
   • 测试 与目标实例的连接。
   • 根据 需要强制重试任何队列项。
   注意

   请勿在发布实例上对反向复制发件箱使用“测试连接”链接。

   如果对发件箱队列执行复制测试，则所有早于测试复制的项目都将通过每次反向复制进行重新处理。

   如果此类项目已存在于队列中，则可通过以下XPath JCR查询找到它们，并应将其删除。

   /jcr:root/var/replication/outbox//*[@cq:repActionType='TEST']

同样，您可以开发一个解决方案来检测所有复制代理（位于/etc/replication/author或/etc/replication/publish下），然后检查代理(enabled、disabled)和底层队列(active、idle、blocked)的状态。

监控性能

性能 优化是一个交互式过程，在开发过程中会获得焦点。部署后，通常会在特定的间隔或事件后进行审核。

在收集信息以进行优化时使用的方法也可用于持续监控。

下面列出了发生的常见性能问题，以及关于如何发现和消除这些问题的建议。

区域	症状	要增加容量……	要减少音量……
客户端	客户端CPU使用率较高。	安装性能更高的客户端CPU。	简化(HTML)布局。
	服务器CPU使用率较低。	升级到更快的浏览器。	改进客户端缓存。
	有些客户很快，有些很慢。
服务器
网络	服务器和客户端的CPU使用率都较低。	消除网络瓶颈。	改进/优化客户端缓存的配置。
	在服务器上本地浏览的速度（相对）较快。	增加网络带宽。	减轻网页的“粗细”（例如，图像较少、优化了HTML）。
Web服务器	Web服务器上的CPU使用率很高。	群集Web服务器。	减少每页面（访问）的点击量。
		使用硬件负载平衡器。
应用程序	服务器CPU使用率很高。	集群您的AEM实例。	搜索并消除CPU和内存挂起（使用代码审阅、计时输出等）。
	内存消耗高。		改进所有级别的缓存。
	响应时间较短。		优化模板和组件（例如，结构、逻辑）。
存储库
缓存

性能问题可能源于许多与网站无关的原因，包括连接速度、CPU负载等方面的暂时缓慢。

它还可能会影响所有访客，或仅影响访客的子集。

在优化一般性能或解决特定问题之前，需要获取、排序和分析所有这些信息。

• 在遇到性能问题之前：

  • 收集尽可能多的信息，以建立正常情况下系统的良好工作知识

• 当您遇到性能问题时：

  • 尝试在您知道具有良好常规性能的其他客户端上和/或在服务器本身（如果可能）上用一个（或更多）标准Web浏览器复制它

  • 检查任何内容（与系统相关）是否在适当的时间空间内发生了更改，以及这些更改中是否有可能影响性能

  • 提问，例如：

    • 问题是否仅在特定时间发生？
    • 问题是否仅在特定页面上发生？
    • 其他请求是否受到影响？

  • 在正常情况下收集尽可能多的信息与您对系统的了解进行比较：

用于监控和分析性能的工具

下面简要介绍了可用于监控和分析性能的一些工具。

其中某些操作取决于您的操作系统。

工具	用于分析……	使用情况/更多信息……
request.log	响应时间和并发性。	解释request.log。
桁架/地形	页面加载次数	用于跟踪系统调用和信号的Unix/Linux命令。 将日志级别增加到INFO。 分析每个请求加载的页面数量，以及哪些页面等。
线程转储	观察JVM线程。 识别争议、锁和长跑者。	取决于操作系统： - Unix/Linux:kill -QUIT <pid> - Windows（控制台模式）：Ctrl-Break 还提供分析工具，如TDA。
堆转储	内存不足问题导致性能缓慢。	在对AEM的java调用中添加： -XX:+HeapDumpOnOutOfMemoryError 选项。 请参阅《Java SE 6与热点VM的疑难解答指南》。
系统调用	确定时间问题。	对System.currentTimeMillis()或com.day.util的调用。Timing用于从代码或通过HTML-comments生成时间戳。 注意： 应实施这些功能，以便能够根据需要激活/停用它们；当系统运行顺利时，不需要收集统计信息的开销。
阿帕奇·本奇	识别内存泄漏，有选择地分析响应时间。	基本用法为： ab -k -n <requests> -c <concurrency> <url> 有关完整的详细信息，请参阅Apache Bench和ab手册页。
搜索分析		脱机执行搜索查询，确定查询的响应时间，测试并确认结果集。
JMeter	加载和功能测试。	https://jakarta.apache.org/jmeter/
JProfiler	深入分析CPU和内存。	https://www.ej-technologies.com/
JConsole	观察JVM量度和线程。	用法：jconsole 请参阅jconsole和使用JConsole监控性能。 注意： 通过JDK 1.6,JConsole可通过插件进行扩展；例如，Top或TDA（线程转储分析器）。
Java VisualVM	观察JVM量度、线程、内存和分析。	用法：jvisualvm或visualvm 请参阅jvisualvm、visualvm和使用(J)VisualVM监控性能。 注意： 通过JDK 1.6,VisualVM可通过插件进行扩展。
桁架/地带，lsof	深入的内核调用和过程分析(Unix)。	Unix/Linux命令。
时间统计	请参阅页面渲染的时间统计信息。	要查看页面渲染的时间统计信息，可以将Ctrl-Shift-U与URL中设置的?debugClientLibs=true结合使用。
CPU和内存分析工具	在开发过程中分析缓慢的请求时使用。	例如，YourKit。
信息收集	安装的持续状态。	尽可能了解您的安装情况还可以帮助您跟踪导致性能变化的原因，以及这些更改是否合理。 需要定期收集这些量度，以便您能够轻松查看重大更改。

解释request.log

此文件记录有关对AEM发出的每个请求的基本信息。 从这一有价值的结论中可以提取出来。

request.log提供了一种内置方式，用于查看请求需要多长时间。 出于开发目的，tail -f和request.log在响应缓慢时，会非常有用。 要分析更大的request.log，我们建议使用 rlog.jar，以便对响应时间进行排序和筛选。

我们建议从request.log中隔离“慢”页面，然后单独调整这些页面以获得更好的性能。 这通常通过包括每个组件的性能量度或使用性能分析工具（如 [yourkit](https://www.yourkit.com/)）来完成。

监控您网站上的流量

请求日志记录发出的每个请求以及发出的响应：

09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms

通过在特定时段内（例如，在24小时内）合计所有GET条目，您可以对网站上的平均流量进行声明。

使用request.log监控响应时间

性能分析的一个好起点是请求日志：

<cq-installation-dir>/crx-quickstart/logs/request.log

日志如下所示（为简便起见，缩短了各行）：

31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms

此日志中每个请求或响应有一行：

• 发出每个请求或响应的日期。

• 请求的编号，用方括号括起来。 此数字与请求和响应的数字匹配。

• 一个箭头，指示这是请求（指向右侧的箭头）还是响应（向左的箭头）。

• 对于请求，行包含：

  • 方法(通常为GET、HEAD或POST)
  • 请求的页面
  • 协议

• 对于响应，行包含：

  • 状态代码（200表示“success”，404表示“页面未找到”）
  • MIME类型
  • 响应时间

使用小脚本，您可以从日志文件中提取所需信息并汇编所需的统计信息。 从中，您可以看到哪些页面或页面类型缓慢，以及整体性能是否令人满意。

使用request.log监控搜索响应时间

搜索请求也会在日志文件中注册：

31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms

因此，与上面一样，您可以使用脚本来提取相关信息并构建统计信息。

但是，确定响应时间后，您可能需要分析请求为何需要花费时间，以及可以采取哪些措施来改进响应。

监控并发用户数量和影响

同样，request.log可用于监视并发以及系统对它的反应。

必须进行测试以确定系统可以处理的并发用户数，才能看到负面影响。 同样，可以使用脚本从日志文件中提取结果：

• 监视在特定时间范围内发出的请求数，例如一分钟
• 同时（尽可能接近）测试特定数量的用户发出相同请求的效果；例如，30个用户同时单击​Save。

31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms

使用rlog.jar查找持续时间较长的请求

AEM包括位于以下位置的各种帮助程序工具：
<cq-installation-dir>/crx-quickstart/opt/helpers

其中一个(rlog.jar)可用于快速排序request.log，以便按持续时间显示请求，从最长到最短的时间。

以下命令显示可能的参数：

$java -jar rlog.jar
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG
Usage:
  java -jar rlog.jar [options] <filename>
Options:
  -h               Prints this usage.
  -n <maxResults>  Limits output to <maxResults> lines.
  -m <maxRequests> Limits input to <maxRequest> requests.
  -xdev            Exclude POST request to CRXDE.

例如，您可以运行它以指定request.log文件作为参数，并显示持续时间最长的10个前请求：

$ java -jar ../opt/helpers/rlog.jar -n 10 request.log
*Info * Parsed 464 requests.
*Info * Time for parsing: 22ms
*Info * Time for sorting: 2ms
*Info * Total Memory: 1mb
*Info * Free Memory: 1mb
*Info * Used Memory: 0mb
------------------------------------------------------
     18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html
      2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript
      1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html
      1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html
      1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript
      1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
      1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript
      1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
      1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json
      1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8

如果需要对大型数据采样执行此操作，可能需要连接单个request.log文件。

Apache Bench

为了最大限度地减少特殊情况（如垃圾收集等）的影响，建议使用诸如apachebench之类的工具（例如，有关进一步文档，请参阅ab），以帮助识别内存泄漏并有选择地分析响应时间。

Apache Bench可通过以下方式使用：

$ ab -c 5 -k -n 1000 "http://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503

Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes

Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106

Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)

上述数字取自访问geometrixx公司页面的标准MAcBook Pro笔记本电脑（2010年年中），该页面包含在默认AEM安装中。 页面非常简单，但并未针对性能进行优化。

apachebench 还显示每个请求的时间作为平均值，涵盖所有并发请求；请参 Time per request: 54.595 [ms] 阅（跨所有并发请求的平均值）。您可以更改并发参数-c的值（一次要执行的多个请求数），以查看任何效果。

请求计数器

有关请求流量（特定时间段内的请求数）的信息会指示实例的负载。 此信息可从request.log中提取，但使用计数器将自动收集数据，以便您查看：

• 活动方面存在显着差异（即区分“多个请求”和“活动量低”）
• 当未使用实例时
• 任何重新启动（计数器重置为0）

要自动收集信息，您还可以安装RequestFilter ，以在每个请求中递增一个计数器。 多个计数器可用于不同的时间段。

收集的信息可用于指示：

• 活动的重大变化
• 冗余实例
• 任何重新启动（计数器重置为0）

HTML注释

为了提高服务器性能，建议每个项目都包含html comments。 可以找到许多好的公共例子；选择一个页面，打开页面源进行查看并滚动到底部，可以看到以下代码：

</body>
 </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

使用JConsole监控性能

工具命令jconsole可在JDK中使用。

1. 启动AEM实例。

2. 运行 jconsole.

3. 选择您的AEM实例并​Connect。

4. 在Local应用程序内，双击com.day.crx.quickstart.Main;将默认显示概述：

   

   之后，您可以选择其他选项。

使用(J)VisualVM监控性能

自JDK 1.6起，工具命令jvisualvm便可用。 安装JDK 1.6后，您可以：

1. 启动AEM实例。

   注意

   如果使用Java 5，则可以将-Dcom.sun.management.jmxremote参数添加到启动JVM的java命令行中。 默认情况下，Java 6会启用JMX。

2. 运行以下任一操作：

   • jvisualvm:在JDK 1.6 bin文件夹中（已测试版本）
   • visualvm:可以从VisualVM 🔗 （放血边缘版本）下载

3. 在Local应用程序内，双击com.day.crx.quickstart.Main;将默认显示概述：

   

   之后，您可以选择其他选项，包括监视器：

   

您可以使用此工具生成线程转储和内存头转储。 技术支持团队通常要求提供此信息。

信息收集

尽可能了解您的安装情况有助于您跟踪哪些因素可能导致性能变化，以及这些变化是否合理。 需要定期收集这些量度，以便您能够轻松查看重大更改。

以下信息可能会很有用：

• 有多少位作者在使用该系统？
• 每天平均激活页面的次数是多少？
• 您当前在此系统上维护多少页？
• 如果使用MSM，则每月平均转出次数是多少？
• 每月的平均Live Copy数是多少？
• 如果您使用AEM Assets，则当前在Assets中维护多少个资产？
• 资产的平均大小是多少？
• 当前使用了多少个模板？
• 当前使用了多少个组件？
• 在高峰时间，您在创作系统上每小时有多少个请求？
• 在高峰时间，您在发布系统上每小时有多少个请求？

有多少位作者在使用该系统？

要查看自安装以来使用系统的作者人数，请使用命令行：

cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l

要查看在给定日期工作的作者人数，请执行以下操作：

grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l

每天平均激活页面的次数是多少？

查看自服务器安装以来使用存储库查询的页面激活总数；通过CRXDE — 工具 — 查询：

• 类型 XPath

• 路径 /

• 查询 //element(*, cq:AuditEvent)[@cq:type='Activate']

然后，计算自安装以来经过的天数，以计算平均值。

您当前在此系统上维护多少页？

若要查看服务器上当前的页数，请使用存储库查询；通过CRXDE — 工具 — 查询：

• 类型 XPath

• 路径 /

• 查询 //element(*, cq:Page)

如果使用MSM，则每月平均转出次数是多少？

确定安装后使用存储库查询的转出总数；通过CRXDE — 工具 — 查询：

• 类型 XPath

• 路径 /

• 查询 //element(*, cq:AuditEvent)[@cq:type='PageRolledOut']

计算自安装以来经过的月数以计算平均值。

每月的平均Live Copy数是多少？

确定自安装后使用存储库查询的Live Copy总数；通过CRXDE — 工具 — 查询：

• 类型 XPath

• 路径 /

• 查询 //element(*, cq:LiveSyncConfig)

再次使用安装后经过的月数来计算平均值。

如果您使用AEM Assets，则当前在Assets中维护多少个资产？

要查看您当前维护的DAM资产数量，请使用存储库查询；通过CRXDE — 工具 — 查询：

• 类型 XPath

• 路径 /

• 查询 /jcr:root/content/dam//element(*, dam:Asset)

资产的平均大小是多少？

要确定/var/dam文件夹的总大小，请执行以下操作：

1. 使用WebDAV将存储库映射到本地文件系统。

2. 使用命令行：

   cd /Volumes/localhost/var
   du -sh dam/
   

   要获取平均大小，请将全局大小除以/var/dam中的资产总数（如上所示）。

当前使用了多少个模板？

若要查看服务器上当前的模板数，请使用存储库查询；通过CRXDE — 工具 — 查询：

• 类型 XPath

• 路径 /

• 查询 //element(*, cq:Template)

当前使用了多少个组件？

要查看服务器上当前组件的数量，请使用存储库查询；通过CRXDE — 工具 — 查询：

• 类型 XPath

• 路径 /

• 查询 //element(*, cq:Component)

在高峰时间，您在创作系统上每小时有多少个请求？

要确定在高峰时间您在创作系统上的每小时请求数，请执行以下操作：

1. 要确定自安装以来的请求总数，请使用命令行：

   cd <cq-installation-dir>/crx-quickstart/logs
   grep -R "\->" request.log | wc -l
   

2. 要确定开始和结束日期，请执行以下操作：

   vim request.log
   G / 1G: for the last/first lines
   

   使用这些值可计算自安装以来经过的小时数，以及每小时的平均请求数。

在高峰时间，您在发布系统上每小时有多少个请求？

对您的发布实例重复上述步骤。

分析特定情景

下面列出了一些建议，说明在开始遇到某些性能问题时要检查哪些内容。 （不幸的）清单并不完全。

100%的CPU

如果系统的CPU以100%的速度持续运行，请查看：

• 知识库：

  • 分析慢速和阻止的进程

内存不足

尽管在开发和测试期间应检测到此类错误，但某些情况可能会漏掉。

如果您的系统内存不足，则可以通过各种方式查看此情况，包括性能下降和错误消息（包括子文本）：

java.lang.OutOfMemoryError

在这些情况下，请检查：

• 用于启动AEM的JVM设置

• 知识库：

  • 分析内存问题

磁盘I/O

如果您的系统磁盘空间不足，或者您发现磁盘崩溃开始出现，请参阅：

• 是否禁用了调试信息的收集；可以在各种位置进行配置，包括：

  • Apache Sling JSP脚本处理程序
  • Apache Sling Java脚本处理程序
  • Apache Sling日志记录配置
  • CQ HTML库管理器
  • CQ WCM调试过滤器
  • 记录器

• 是否配置了版本清除以及配置方式

• 知识库：

  • 打开的文件过多
  • 日志占用太多磁盘空间

常规性能下降

如果您看到实例在每次重新引导后（有时一周或更晚）性能恶化，则可以检查以下内容：

• 内存不足

• 知识库：

  • 未结会话

JVM优化

Java虚拟机(JVM)在调整方面有了显着改进（尤其是自Java 7以来）。 因此，指定合理的固定JVM大小和使用默认值通常是合适的。

如果默认设置不合适，则在尝试调整JVM之前，必须建立一种方法来监控和评估GC性能；这可能涉及监控因素，包括堆大小、算法等。

一些常见的选择包括：

• VerboseGC:

  -verbose:gc \
   -Xloggc:$LOGS/verbosegc.log \
   -XX:+PrintGCDetails \
   -XX:+PrintGCDateStamps
  

生成的日志可由GC可视化器摄取，例如：

[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)

或JConsole:

• 这些设置适用于“宽打开”JMX连接：

  -Dcom.sun.management.jmxremote \
   -Dcom.sun.management.jmxremote.port=8889 \
   -Dcom.sun.management.jmxremote.authenticate=false \
   -Dcom.sun.management.jmxremote.ssl=false
  

• 然后，使用JConsole连接到JVM;请参阅：
  [https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html](https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html)

这将帮助您了解正在使用的内存量、GC算法的使用情况、运行时间以及这对应用程序性能有何影响。 如果没有这一点，调整就只是“随机摆弄旋钮”。