request.log分析範例 | AEM
Adobe Experience Manager (AEM)的request.log是豐富的資訊來源,包括回應時間,這對分析效能問題至關重要。 本文提供幾個範例來說明這一點。
說明 description
環境
Experience Manager 6.5
問題/症狀
Adobe Experience Manager (AEM) request.log包含各種有用的資訊,例如回應時間,可用於分析效能問題。 以下是使用Linux命令的分析範例清單(包括某些外部命令,例如ruby [ 1]和datamash [ 2] )。
安裝指南
[ 1] https://www.ruby-lang.org/en/documentation/installation/
[ 2] https://www.gnu.org/software/datamash/download/
解決方法 resolution
目錄
A。簡介
request.log的格式
B。準備步驟
- 資料清除
- 重新啟動時間
- 每小時存取次數
- 最大並行處理數
- 分割記錄檔
- 合併要求記錄和回應記錄
C。分析範例
- 最多次存取
- 存取遺失的回應
- 緩慢存取
- 回應時間的時間序列資料
- 最小值、平均值(平均)、中位數、最長回應時間
- 每個期間的存取次數
- 每個期間的回應狀態數
- 最常見的URL
access.log記錄的request.log記錄
天結論
A。簡介
request.log的格式:
AEM 6.5預設會以下列格式產生request.log。 由於系統限制,本文中的命令列以影像顯示而非純文字。
request.log的範例:
在本文中,包含「 — >」的行稱為「請求記錄」。 含有"< -"的行是「回應記錄」。
要求記錄:
AEM收到請求時,會記錄請求記錄。 記錄中會包含接收日期和時間、要求 ID、要求方法和 URL。
回應記錄:
AEM回應請求時,會記錄回應記錄。 記錄中會包含回應的日期和時間、要求 ID、狀態代碼、內容類型和回應時間 (以毫秒為單位)。
在解譯request.log上尋找對應的手冊。
B。準備步驟
步驟 1.資料清理
在深入分析request.log之前,請務必標準化記錄檔記錄。
第一個sed命令會移除回應記錄中Content-Type的額外空格,以防止以空格分隔錯誤欄位。 ruby命令(請參閱上面的 [ 1] 以安裝Ruby)會將日期格式轉換為ISO 8601。 Ruby 命令還會用空格取代冒號來分隔日期和時間。
步驟 2.重新啟動的時間
重新啟動AEM且Service Pack安裝會重設request.log的請求ID。 請求ID = 0的要求記錄表示可能有這些型別的作業。
在上面的範例中,在 13:08:49 和 13:26:13 處將要求 ID 重設為 0。
步驟 3.每小時存取次數
計算request.log的每小時存取次數與時間範圍。
步驟 4.同時處理的最大值
同時處理的數量有助於猜測 AEM 的伺服器負載。
預設情況下,將 AEM 中 Jetty 的最大同時連線數設定為 200。完成回應後解除通訊端時發生延遲。當同時處理的數量超過約 170 時,它會變得無法接受新的要求。
步驟 5.分割記錄檔
當AEM重新啟動或安裝Service Pack時,會重設request.log的要求識別碼。 由於此行為,當request.log包含此類操作時,分析可能不正確。 若要執行精確分析並降低一次處理的檔案大小,請使用請求request.log的要求記錄分割ID = 0。
步驟 6.合併要求記錄和回應記錄
依據要求 ID 來合併要求和回應記錄能因此更容易在效能問題開始時即刻發現。這個合併的記錄檔將會在稍後的範例中使用。
最後sed命令將虛擬回應新增至沒有對應回應記錄的要求記錄。 也可能有不包含要求記錄的回應記錄。但這類記錄可忽略,因為這些通常不是需要調查的問題。
合併的紀錄檔應該如下所示:
C。分析範例
範例 1. 最大量存取
將合併後的記錄檔依據回應時間以遞減順序排序,包括沒有回應的存取。
範例 2. 缺少回應的存取
使用虛擬回應時間來擷取缺少相對應回應記錄的存取。
如果在沒有回應的情況下接收存取的時間與伺服器負載的增加相互關聯,則這些存取可能已經觸發了效能問題。
範例 3.慢速存取
擷取花費 10 秒以上的存取。
當點選數太高時,請在[ 0-9] {5}命令中將[ 0-9] {6}取代為grep,以縮小存取範圍,使其耗用超過100秒。
範例 4. 回應時間的時間序列資料
從資料中僅擷取時間戳記和回應時間有助於建立圖表。
省略立即回應的存取使得資料更有效率。以下範例擷取花費超過一秒的存取。
範例 5. 回應時間最小值、中間值 (平均)、中位值、最大值
以上範例使用 datamash 命令 (https://www.gnu.org/software/datamash/) 進行統計處理。如果紀錄中包含無回應的存取,則虛擬值將影響結果。
範例 6. 一段時間內的存取次數
計算每十分鐘的存取次數。此結果有助於確定大流量是否導致了效能問題。
以下範例將資料範圍縮小到僅限 POST 要求。一個典型的使用案例是確定內容製作或複製是否集中到發佈階層。
範例 7. 一段時間內的回應狀態次數
使用 datamash 命令建立每十分鐘每個回應狀態數的表格。
範例 8. 最常見的 URL
列印每十分鐘存取最頻繁的前三大 URL。
範例 9. request.log 紀錄的 access.log 記錄
搜尋access.log對應到特定要求識別碼的記錄。
如果同時發生對同一個URL的多次存取,結果會顯示單一要求識別碼的多個access.log記錄。
天結論
本文中的範例應可協助您分析效能問題。
清單中的範例已經在 CentOS 7.5 和 Ubuntu 22.04LTS 上進行了測試,但它們可能無法按預期運作,實際情況會依據您的環境而定,例如不同版本或命令的變化。因此請根據您環境中安裝的命令對其進行調整。