監視和維護您的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. 按一下「乾式運行」(Dry Run)以預覽清除過程的作用。

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:版本的日期。

在下一個範例中：

• 襯衫​版本會因其版本年齡大於2天而被清除。
• 東加時尚隊！​ 版本會被清除，因為其版本數大於5。

使用審計記錄和日誌檔案

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

使用日誌

AEM WCM會記錄詳細的記錄檔。 開啟包裝並啟動Quickstart後，您可以找到以下日誌：

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

日誌檔案旋轉

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

• error.log檔案會根據模式{original_filename} .yyyy-MM-dd重新命名。 例如，在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對動態媒體提出的每個要求。

  • 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為資訊，因此不記錄除錯訊息。

要激活Logger的調試日誌級別，請將屬性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> (as this is a Logger)

   其中，<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)

     值：指定Logger要記錄訊息的OSGi services;例如，以下所有項目：

     • 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>（因為這是寫入器）

     與Logger一樣，<identifier>會由您（必須）輸入以識別例項的自由文字取代（您無法忽略此資訊）。 例如， org.apache.sling.commons.log.LogManager.factory.writer-MINE

   • 類型: sling:OsgiConfig

   注意

   雖然不是技術要求，但建議使<identifier>變為唯一。

   在此節點上設定以下屬性：

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

     類型: String

     值：指定Log File，使其與Logger；中指定的檔案匹配

     在此範例中，../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. 您應「逸出」一對單引號(' ')中的常值文字；

   這是為了避免某些字元被解譯為圖樣字母。

   1. 在選項中的任何位置，僅允許使用有效檔案名的字元。

5. 使用您選擇的工具讀取您的新記錄檔。

   此示例建立的日誌檔案為../crx-quickstart/logs/myLogFile.log。

Felix Console也提供../system/console/slinglog;例如http://localhost:4502/system/console/slinglog。

查找審計記錄

會保存審計記錄，以記錄誰在何時執行了什麼。 AEM WCM和OSGi事件都會產生不同的稽核記錄。

AEM WCM審核記錄在「編寫頁面」時顯示

1. 開啟頁面。

2. 從側鏈中，您可以選擇帶有鎖定表徵圖的頁籤，然後按兩下​審計日誌……

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

   

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

資料庫中的AEM WCM審核記錄

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

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

OSGi Audit records from the Web Console

OSGi事件也會產生稽核記錄，您可從AEM Web Console的「設定狀態」標籤->「記錄檔」標籤中查看：​​

監視複製代理

您可以監視複製隊列以檢測隊列何時關閉或被阻止——這反過來可能表示發佈實例或外部系統有問題：

• 所有必要的隊列都啟用了嗎？

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

• 所有enabled隊列應具有idle或active狀態，這表示正常操作；沒有隊列應該是blocked ，這通常是接收器端出現問題的一個標誌。

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

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

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

2. 按一下​Replication。

3. 連按兩下適當環境（左窗格或右窗格）的代理連結；例如，作者​上的代理。

   生成的窗口顯示了作者環境的所有複製代理的概述，包括其目標和狀態。

4. 按一下相應的代理名（即連結）以顯示有關該代理的詳細資訊：

   

   您可以：

   • 查看是否啟用了代理。
   • 查看任何複製的目標。
   • 查看複製隊列當前是否處於活動狀態（已啟用）。
   • 瞭解佇列中是否有任何項目。
   • 重 新整理 ​​Clear，以更新佇列項目的顯示；這可協助您查看項目進入並離開佇列。
   • 查看 日誌以訪問複製代理的任何操作的日誌。
   • 測試 目標實例的連接。
   • 如有 需要，強制重試任何佇列項目。
   注意

   請勿在發佈實例的「反向複製輸出」框中使用「測試連接」連結。

   如果對Outbox隊列執行複製測試，則所有早於測試複製的項目都將通過每個反向複製重新處理。

   如果此類項目已存在於隊列中，則可使用以下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伺服器	網頁伺服器上的CPU使用量很高。	叢集您的Web伺服器。	減少每頁點擊（瀏覽）。
		使用硬體負載平衡器。
應用程式	伺服器CPU使用量很高。	叢集您的AEM例項。	搜尋並消除CPU和記憶體記憶體記憶體記憶體記憶體記憶體記憶體（使用程式碼檢閱、計時輸出等）。
	高記憶體消耗。		改善所有層級的快取。
	回應時間較短。		最佳化範本和元件（例如結構、邏輯）。
存放庫
快取

效能問題可能源自許多與您網站無關的原因，包括連線速度的暫時慢速、CPU負載等。

此外，它也可能會影響您的所有訪客，或僅影響其中的子集。

您必須先取得、排序和分析所有這些資訊，才能最佳化整體效能或解決特定問題。

• 在遇到效能問題之前：

  • 收集盡可能多的資訊，以建立正常情況下系統的良好工作知識

• 當您遇到效能問題時：

  • 嘗試在您知道具有良好一般效能的不同用戶端上，使用一個（或更好）標準網頁瀏覽器複製它，以及／或在伺服器本身（如果可能）複製它

  • 檢查是否在適當的時間空間內有任何變更（與系統相關），以及這些變更中是否有可能影響效能

  • 提出以下問題：

    • 問題是否只發生在特定時間？
    • 問題是否只發生在特定頁面上？
    • 其他請求是否受到影響？

  • 收集盡可能多的資訊，以便與您在正常情況下的系統知識進行比較：

監控和分析效能的工具

以下簡要概述了一些可用於監視和分析效能的工具。

其中一些將取決於您的作業系統。

工具	用於分析……	使用／詳細資訊……
request.log	回應時間與並行處理。	解讀request.log。
桁架／桁架	頁面載入	用於跟蹤系統調用和信號的Unix/Linux命令。 將日誌級別提高到INFO。 分析每個請求的頁面載入次數，以及哪些頁面等。
線程轉儲	觀察JVM線程。 識別競爭、鎖定和長跑者。	取決於作業系統： - Unix/Linux:kill -QUIT <pid> - Windows（控制台模式）:Ctrl-Break 也提供分析工具，例如TDA。
堆轉儲	記憶體不足導致效能降低。	新增： -XX:+HeapDumpOnOutOfMemoryError 選項至AEM的java呼叫。 請參見《Java SE 6 with HotSpot VM的故障排除指南》。
系統呼叫	識別時間問題。	對System.currentTimeMillis()或com.day.util的呼叫。Timing會用來從您的程式碼產生時間戳記，或透過HTML-comments產生時間戳記。 注意： 這些應該實作，以便視需要啟用／停用；當系統運行順利時，不需要收集統計資訊的開銷。
Apache Bench	識別記憶體洩漏，選擇性分析回應時間。	基本用法為： 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 請參閱「使用(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表示「page not found」）
  • 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可用於監視併發以及系統對它的反應。

必須進行測試，以判斷系統可處理的並行使用者數，才會看到負面影響。 Again scripts can be used to extract results from the log file:

• 監控特定時段（例如一分鐘）內發出的請求數
• 測試特定數量的使用者同時提出相同要求（盡可能接近）的效果；例如，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:在JDK 1.6 bin資料夾中（已測試版本）
   • 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

每天啟動頁面的平均次數是多少？

查看自伺服器安裝以來使用儲存庫查詢的頁面激活總數；via CRXDE - Tools - Query:

• 類型 XPath

• 路徑 /

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

然後計算安裝後經過的天數，以計算平均值。

您目前在此系統上維護多少頁？

查看伺服器上當前使用儲存庫查詢的頁數；via CRXDE - Tools - Query:

• 類型 XPath

• 路徑 /

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

如果您使用MSM，每個月的平均推廣次數是多少？

要確定自安裝以來使用儲存庫查詢的推出總數；via CRXDE - Tools - Query:

• 類型 XPath

• 路徑 /

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

計算自安裝以來經過的月數，以計算平均值。

每月的即時副本平均數是多少？

要確定自安裝以來使用儲存庫查詢建立的即時拷貝總數；via CRXDE - Tools - Query:

• 類型 XPath

• 路徑 /

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

再次使用安裝後經過的月數來計算平均值。

如果您使用AEM Assets，您目前在Assets中會維護多少資產？

要查看您當前維護的DAM資產數量，請使用儲存庫查詢；via CRXDE - Tools - Query:

• 類型 XPath

• 路徑 /

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

資產的平均規模是多少？

要確定/var/dam資料夾的總大小，請執行以下操作：

1. 使用WebDAV將儲存庫映射到本地檔案系統。

2. 使用命令行：

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

   若要取得平均大小，請將全域大小除以/var/dam（上方取得）中的資產總數。

目前使用多少個範本？

要查看伺服器上當前使用儲存庫查詢的模板數；via CRXDE - Tools - Query:

• 類型 XPath

• 路徑 /

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

目前使用多少個元件？

要查看伺服器上當前使用儲存庫查詢的元件數；via CRXDE - Tools - Query:

• 類型 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 Library Manager
  • CQ WCM除錯篩選
  • 伐木工

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

• 知識庫：

  • 開啟的檔案太多
  • 日誌佔用太多磁碟空間

常規效能降級

如果您看到實例在每次重新引導後（有時一週或更晚）效能惡化，則可以檢查以下內容：

• 記憶體不足

• 知識庫：

  • 未關閉的會話

JVM優化

Java Virtual Machine(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演算法、執行時間，以及這對您的應用程式效能有何影響。 若沒有這一點，調音就只是「隨意擺弄旋鈕」。