監視和維護您的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. 按一下​清除​以啟動進程。

分析控制台

乾式運行​和​清除​進程列出所有已處理的節點。 在過程中，節點可以具有以下狀態之一：

• ignore (not versionnable):節點不支援版本設定，且在處理期間會忽略。
• ignore (no version):節點沒有任何版本，在處理期間會被忽略。
• retained:未清除該節點。
• purged:已清除節點。

此外，主控台還提供版本的實用資訊：

• V 1.0:版本號碼。
• V 1.0.1*星號表示版本為當前版本。
• Thu Mar 15 2012 08:37:32 GMT+0100:版本日期。

在下一個範例中：

• 會清除​Thorts​版本，因為其版本年齡超過2天。
• 東加時尚隊！ 版本會清除，因為其版本數大於5。

使用審核記錄和日誌檔案

您可以在不同位置找到與Adobe Experience Manager(AEM)相關的稽核記錄和記錄檔。 以下提供您可在何處找到的概觀。

使用日誌

AEM WCM記錄詳細記錄。 開啟快速入門程式後，您可以在中找到日誌：

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

日誌檔案旋轉

日誌檔案旋轉是指通過定期建立新檔案來限制檔案增長的過程。 在AEM中，名為error.log的記錄檔會根據指定規則每天旋轉一次：

• 會根據模式{original_filename} .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

    只有在啟用動態媒體時，才會使用此記錄檔。 它提供用於分析內部ImageServer進程的行為的統計資訊和分析資訊。

  • request.log

    每個存取請求都會與回應一併註冊。

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

    只有在啟用動態媒體時，才會使用此記錄檔。 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 Logging Configuration為資訊，因此不會記錄除錯訊息。

要激活記錄器的調試日誌級別，請將屬性org.apache.sling.commons.log.level設定為在儲存庫中調試。 例如，在/libs/sling/config/org.apache.sling.commons.log.LogManager上設定全域Apache Sling Logging。

除錯檔案中的一行通常以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 Logging Logger Configuration建立節點：

   • 名稱:

   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 最多支援6個引數。

   {0}類型java.util.Date的時間戳

   {1}日誌標籤

   {2}當前線程的名稱

   {3}記錄器的名稱

   {4}日誌級別

   {5}日誌消息

   如果記錄呼叫包含Throwable，則stacktrace會附加至訊息。

   注意

   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 Logging Writer Configuration建立節點：

   • 名稱：org.apache.sling.commons.log.LogManager.factory.writer-<identifier>（因為這是寫入程式）

     與記錄器一樣， <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 Console也會在../system/console/slinglog提供Sling記錄支援的相關資訊；例如http://localhost:4502/system/console/slinglog。

查找審核記錄

保留審計記錄，以便提供記錄，記錄誰做了什麼和何時做了什麼。 會為AEM WCM和OSGi事件產生不同的稽核記錄。

AEM WCM稽核記錄在頁面編寫時顯示

1. 開啟頁面。

2. 從sidekick中，可以選擇帶有鎖表徵圖的頁簽，然後按兩下​審核日誌……

3. 將會開啟一個新視窗，顯示目前頁面的稽核記錄清單。

   

4. 要關閉窗口時，按一下​OK。

AEM儲存庫內的WCM審核記錄

在/var/audit資料夾中，根據資源保留審計記錄。 您可以深入研究，直到看到個別記錄及其包含的資訊為止。

這些條目包含的資訊與編輯頁面時顯示的資訊相同。

OSGi從Web控制台審核記錄

OSGi事件也會產生稽核記錄，您可從AEM Web主控台的​Configuration Status​標籤 — > Log Files​標籤查看：

監視複製代理

您可以監視復寫佇列以偵測佇列是否關閉或封鎖，而這又可能表示發佈執行個體或外部系統有問題：

• 是否所有必要隊列都啟用？

• 是否仍需要禁用的隊列？

• 所有enabled隊列都應具有狀態idle或active，這表示正常操作；隊列不應為blocked，這通常是接收方問題的徵兆。

• 如果隊列的大小隨著時間而增大，這可能表示已阻止的隊列。

要監視複製代理，請執行以下操作：

1. 存取AEM中的​Tools​標籤。

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。
堆轉儲	記憶體不足，導致效能緩慢。	將： -XX:+HeapDumpOnOutOfMemoryError 選項新增至對AEM的java呼叫。 請參閱《Java SE 6與HotSpot 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可透過外掛程式擴充。
桁架/橫架，lof	深入的內核調用和進程分析(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命令行中。 JMX預設為透過Java 6啟用。

2. 執行下列任一項：

   • jvisualvm:（測試版本）
   • visualvm:可從VisualVM下 載 （出血邊緣版本）

3. 在Local應用程式內，按兩下com.day.crx.quickstart.Main;預設會顯示「概述」：

   

   之後，您可以選取其他選項，包括監視器：

   

您可以使用此工具生成線程轉儲和記憶體頭轉儲。 技術支援團隊經常要求提供這些資訊。

資訊收集

盡可能了解您的安裝情況有助於您跟蹤哪些因素可能導致效能更改，以及這些更改是否正確。 這些量度需定期收集，以便輕鬆查看重大變更。

下列資訊可能很實用：

• 有多少作者使用此系統？
• 每天啟動的平均頁面數是多少？
• 您當前在此系統上維護多少頁？
• 如果您使用MSM，每月的平均轉出數量為何？
• 每月的即時副本平均數量是多少？
• 如果您使用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總數；通過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算法、運行所花的時間，以及這對應用程式效能的影響。 如果沒有這個，調音只是「隨機擺弄旋鈕」。