AEM_Interpreting the request.log

Monitoring traffic on your website:

• The request log registers each request made, together with the response made:

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

• By totaling all the GET entries within a specific periods (e.g. over various 24 hour periods) you can make statements about the average traffic on your website.

Monitoring response times with the CQ request.log

• A good starting point for performance analysis is the request log:

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

• The log looks as follows (the lines are shortened for simplicity):

1 2 3 4

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

This log has one line per request or response:

• The date at which each request or response was made.
• The number of the request, in square brackets. This number matches for the request and the response.
• An arrow indicating whether this is a request (arrow pointing to the right) or a response (arrow to the left).
• For requests, the line contains:
  • the method (typically, GET, HEAD or POST)
  • the requested page
  • the protocol
• For responses, the line contains:
  • the status code (200 means “success”, 404 means “page not found”
  • the MIME type
  • the response time

You can see which pages or types of pages are slow, and if the overall performance is satisfactory.

Monitoring search response times with the CQ5 request.log

• Search requests are also registered in the log file:

1 2	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] <- 1562ms="" 200="" font="" html="" text="">

• you can use scripts to extract the relevant information and build up statistics.
• However, once you have determined the response time, 
• you may need to analyze why the request is taking the time it does, and what can be done to improve the response.

Monitoring the number and impact of concurrent users

Again the request.log can be used to monitor concurrency and the system's reaction to it.

Tests must be made to determine how many concurrent users the system can handle before a negative impact is seen. Again scripts can be used to extract results from the log file:

• monitor how many requests are made within a specific time span e.g. one minute
• test the effects of a specific number of users all making the same requests at (as close as possible) the same time; e.g. 30 users clicking Save at the same time.

1 2 3 4 5 6 7 8 9 10

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] <- 0ms="" 304="" font="" html="" text=""> 31/Mar/2009:11:45:33 +0200 [334] <- 200="" 31ms="" font="" gif="" image=""> 31/Mar/2009:11:45:38 +0200 [333] <- 200="" 31ms="" font="" gif="" image=""> 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] <- 0ms="" 304="" font="" html="" text=""> 31/Mar/2009:11:45:44 +0200 [337] <- 0ms="" 304="" font="" html="" text="">