request.log analysis의 예 | 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. 소개

B. 준비 단계

C. 분석의 예

일. 결론

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 명령(Ruby를 설치하려면 위의 [ 1] 참조)은 날짜 형식을 ISO 8601로 변환합니다. 또한 ruby 명령은 콜론 대신 공백으로 날짜와 시간을 구분합니다.

2단계. 재실행 시간

AEM을 다시 시작하면 서비스 팩 설치가 request.log의 요청 ID를 재설정합니다. 요청 ID = 0이(가) 있는 요청 레코드는 이러한 종류의 작업이 있을 수 있음을 나타냅니다.

위의 예에서는 요청 ID는 13:08:49 및 13:26:13에서 0으로 재설정되었습니다.

3단계. 시간당 액세스 수

시간당 액세스 횟수와 request.log의 시간 범위를 계산합니다.

4단계. 최대 동시 처리

동시 처리 수는 AEM의 서버 부하를 추측하는 데 도움이 됩니다.

기본적으로 AEM에서 Jetty에 대한 최대 동시 연결 수는 200으로 설정됩니다. 응답을 완료한 후 소켓을 릴리스하는 데 지연이 있습니다. 동시 처리 수가 약 170을 초과하면 새로운 요청을 수락할 수 없게 됩니다.

5단계. 로그 파일 분할

AEM을 다시 시작하거나 서비스 팩을 설치하면 request.log의 요청 ID가 다시 설정됩니다. 이 동작으로 인해 request.log에 이러한 작업이 포함되어 있으면 분석이 올바르지 않을 수 있습니다. 정확한 분석을 수행하고 한 번에 처리되는 파일 크기를 줄이려면 ID = 0 요청과 함께 요청 레코드를 사용하여 request.log을(를) 분할하십시오.

6단계. 요청 레코드와 응답 레코드 병합

요청 ID별로 요청 및 응답 레코드를 병합하면 성능 문제가 시작된 시점을 보다 쉽게 파악할 수 있습니다. 이 병합된 로그 파일은 이후 예에서 사용됩니다.

마지막 sed 명령은 해당 응답 레코드가 없는 요청 레코드에 더미 응답을 추가합니다. 요청 레코드가 없는 응답 레코드도 있을 수 있습니다. 그러나 해당 레코드는 일반적으로 조사 대상이 아니므로 무시할 수 있습니다.

병합된 로그 파일은 다음과 같습니다.

C. 분석 예

예제 1. 가장 많은 액세스

응답 없는 액세스를 포함하여 병합된 로그 파일을 응답 시간별로 내림차순으로 정렬합니다.

예제 2. 누락된 응답에 대한 액세스

더미 응답 시간을 사용하여 해당 응답 레코드가 누락된 액세스를 추출합니다.

응답 없이 액세스를 수신하는 타이밍이 서버 부하의 증가와 관련이 있는 경우 이러한 액세스로 인해 성능 문제가 발생할 수 있습니다.

예제 3. 느린 액세스

10초 이상 소요된 액세스를 추출합니다.

히트 수가 너무 많으면 grep 명령에서 [ 0-9] {5}을(를) [ 0-9] {6}(으)로 바꾸면 100초 이상 걸린 액세스로 범위를 좁힐 수 있습니다.

예제 4. 응답 시간의 시계열 데이터

데이터에서 타임스탬프와 응답 시간만 추출하면 그래프를 만드는 데 유용하게 활용할 수 있습니다.

즉시 응답한 액세스를 생략하면 데이터의 효율성이 향상됩니다. 다음 예제는 1초 이상 소요된 액세스를 추출합니다.

예제 5. 최소, 평균, 중앙값, 최대 응답 시간

위의 예에서는 통계 처리를 위해 datamash 명령(https://www.gnu.org/software/datamash/)을 사용합니다. 로그에 응답 없는 액세스가 포함된 경우 더미 값이 결과에 영향을 미칩니다.

예제 6. 기간별 액세스 수

10분당 액세스 수를 계산합니다. 산출된 결과는 볼륨이 큰 트래픽이 성능 문제를 유발했는지 확인하는 데 도움이 됩니다.

다음 예에서는 데이터의 범위를 POST 요청으로만 좁힙니다. 일반적인 사용 사례는 게시 계층에 콘텐츠 작성 또는 복제가 집중되어 있는지 확인하기 위한 것입니다.

예제 7. 기간별 응답 상태 수

datamash 명령을 사용하여 10분당 각 응답 상태 수를 나타내는 테이블을 작성합니다.

예제 8. 가장 자주 사용되는 URL

10분마다 가장 자주 액세스된 상위 3개의 URL을 인쇄합니다.

예제 9. request.log 레코드에 대한 access.log 레코드

access.log에서 특정 요청 ID에 해당하는 레코드를 검색합니다.

동일한 URL에 동시에 여러 번 액세스한 경우 결과는 단일 요청 ID에 대해 여러 access.log 레코드를 표시합니다.

일. 결론

이 문서의 예는 성능 문제를 분석하는 데 도움이 됩니다.

나열된 예제는 CentOS 7.5 및 Ubuntu 22.04LTS에서 테스트되었지만 다른 버전이나 명령의 변형과 같은 사용자의 환경에 따라 예상대로 작동하지 않을 수 있습니다. 환경에 설치된 명령에 따라 조정하시기 바랍니다.