성능 트리

범위

아래 다이어그램은 성능 문제를 해결하기 위해 수행해야 하는 단계에 대한 지침을 제공하기 위한 것입니다. 그것은 읽기 쉽도록 5개의 부분으로 나뉘어 있다.

다이어그램의 각 단계는 설명서 리소스 또는 권장 사항에 연결됩니다.

사전 요구 사항 및 가정

성능 문제가 지정된 페이지(AEM 콘솔 또는 웹 페이지)에서 관찰되고 일관되게 재현될 수 있다고 가정합니다. 조사를 시작하기 전에 성능을 테스트하거나 모니터링할 수 있는 방법이 반드시 필요합니다.

분석은 0단계에서 시작됩니다. 목표는 성능 문제를 담당하는 개체(디스패처, 외부 호스트 또는 AEM)을 결정한 다음 어떤 영역(서버 또는 네트워크)을 조사해야 하는지를 결정하는 것입니다.

섹션 1

chlimage_1-103

섹션 2

chlimage_1-104

섹션 3

chlimage_1-105

섹션 4

chlimage_1-106

섹션 5

chlimage_1-107

단계 제목 리소스
0단계 요청 흐름 분석

브라우저에서 표준 HTTP 요청 분석을 사용하여 요청 흐름을 분석할 수 있습니다. Chrome에서 이 작업을 수행하는 방법에 대한 자세한 내용은

https://developers.google.com/web/tools/chrome-devtools/profile/network-performance/resource-
loadinghttps://developers.google.com/web/tools/chrome-devtools/profile/network-performance/understanding-resource-timing

2단계 외부 호스트에서 요청이 오고 있습니까? 브라우저에서 표준 HTTP 요청 분석을 사용하여 요청 흐름을 분석할 수 있습니다. Chrome에서 이 작업을 수행하는 방법에 대한 위의 링크를 참조하십시오.
3단계 요청을 캐시할 수 있습니까? 액세스 가능한 요청 및 일반 Dispatcher 성능 최적화 도움말에 대한 자세한 내용은 Dispatcher 성능 최적화를 참조하십시오.
4단계 Dispatcher에서 요청이 오고 있습니까?

Dispatcher 디버깅 설명서에서 요청이 올바르게 캐시되는지 확인합니다.

5단계 디스패처가 AEM을 통해 각 요청을 인증하려고 합니까? 디스패처가 캐시된 리소스를 전달하기 전에 인증을 위해 HEAD 요청을 AEM에 전송하는지 확인합니다. AEM access.log에서 HEAD 요청을 찾아 이렇게 할 수 있습니다. 자세한 내용은 로깅을 참조하십시오.
6단계 디스패처의 지리적 위치가 사용자와 멀리 떨어져 있습니까? 디스패처를 사용자에게 더 가깝게 이동합니다.
7단계 Dispatcher의 네트워크 레이어가 괜찮습니까?
채도 및 지연 문제를 네트워크 레이어를 조사합니다.

8단계 속도 저하는 로컬 인스턴스에서 재현할 수 있습니까?

힘든 날을 사용하여 프로덕션 인스턴스에서 "실제" 조건을 복제합니다. 개발 단계에서 이것이 현실적이지 않은 경우 다른 네트워크 컨텍스트에서 프로덕션 인스턴스(또는 동일한 스테이징 인스턴스)를 테스트하십시오.

9단계 서버의 지리적 위치가 사용자와 멀리 떨어져 있습니까? 서버를 사용자에게 더 가깝게 이동합니다.
10단계 및 29단계 네트워크 레이어 조사

채도 및 지연 문제를 네트워크 레이어를 조사합니다.

작성자 계층의 경우 지연이 100밀리초를 넘지 않는 것이 좋습니다.

성능 최적화 팁에 대한 자세한 내용은 이 페이지를 참조하십시오.

11단계 서버를 더 가깝게 이동하거나 영역당 하나 추가
12단계 AEM 서버 문제 해결 자세한 내용은 다이어그램의 다음 하위 단계를 확인하십시오.
13단계 하드웨어 요구 사항 확인 하드웨어 크기 조정 지침에 대한 설명서를 확인하십시오.
14단계 성능 문제의 원인을 자주 확인
15단계 느린 요청 찾기

request.log을 분석하거나 rlog.jar을 사용하여 슬로우 요청을 확인할 수 있습니다.

rlog.jar 사용에 대한 자세한 내용은 이 페이지를 참조하십시오.

rlog.jar를 사용하여 기간이 긴 요청을 찾습니다.

16단계 프로필 서버

AEM에서 사용할 수 있는 프로파일링 도구에 대한 자세한 내용은 성능 모니터링 및 분석을 위한 도구를 참조하십시오.

17단계 프로파일링 시 슬로우 메서드 찾기
18단계 프로파일링 일반적인 시나리오 성능 최적화 섹션의 특정 시나리오 분석을 참조하십시오.
19단계 100% CPU https://helpx.adobe.com/experience-manager/6-3/sites-deploying/monitoring-and-maintaining.html#MonitoringPerformance
20단계 메모리가 부족합니다.
  1. 메모리 부족
  2. 내 응용 프로그램에서 메모리 부족 오류가 발생합니다.
  3. 도움말의 메모리 문제 분석
21단계 디스크 I/O

모니터링 및 유지 관리 설명서의 디스크 I/O 섹션을 참조하십시오.

단계 22 및 22.1 캐시 비율 디스패처 캐시 비율 계산.

참조
23단계 느린 쿼리 쿼리 및 색인화에 대한 우수 사례
24단계 저장소 조정
25단계 실행 중인 워크플로우

26단계 MSM 인프라

다중 사이트 관리자 우수 사례

27단계 자산 조정
  1. 자산 동기화 서비스
  2. 여러 DAM 인스턴스
  3. 성능 조정 팁 아티클 여기여기.
28단계 닫히지 않은 세션

닫히지 않은 JCR 세션 확인

30단계 디스패처를 더 가깝게 이동("지역"당 하나 추가)
31단계 발송자 앞에 CDN 사용 CDN에 Dispatcher 사용
32단계 디스패처 수준에서 세션 관리를 사용하여 AEM 서버 오프로드

보안 세션 활성화

33단계 요청 액세스 가능
  1. 일반 발송자 구성
  2. 발송자 캐시 구성

캐시 비율을 개선하는 방법;요청 캐시 사용(Dispatcher 우수 사례)

또한 캐싱 구성을 최적화하기 위해 아래 설정을 고려하십시오

  1. GET이 아닌 HTTP 요청에 대한 캐시 없음 규칙 설정
  2. 쿼리 문자열을 캐시할 수 없도록 구성
  3. 누락된 확장으로 URL을 캐시하지 않음
  4. 캐시 인증 헤더(Dispatcher 버전 4.1.10 이후 가능)
34단계 업그레이드 발송자 버전

다음 위치에서 최신 Dispatcher 버전을 다운로드할 수 있습니다.

링크를 따르십시오.

35단계 발송자 구성 Dispatcher 구성
36단계 캐시 무효화 확인
37단계 및 38 레이지 로딩 AEM 웹 성능에 대한 Gem 세션을 참조하십시오.
39단계 사전 연결을 사용하여 연결 오버헤드 감소 위에 표시된 Gem 세션을 참조하십시오. 또한 W3c: https://www.w3.org/TR/resource-hints/#dfn-preconnect에 대한 추가 설명서가 미리 연결됩니다.
단계 40 및 41
외부 호스트 지연 및 응답 시간 외부 호스트에 대한 지연 및 응답 시간을 조사합니다.
단계 45
와 47

HTTP/2 사용 37,38 및 39단계는 Gem Session을 참조하십시오. 또한 HTTP/2 지원에 대한 포럼 게시물을 확인하십시오.
49단계 페이로드 크기 축소 Gzip 을 활성화하고 이미지 크기를 축소합니다.
단계 42 및 43 살아 유지

연결을 다시 사용하기 위해 Keep-Alive 헤더가 다른 요청에 있습니까? 그렇지 않으면 각 요청이 다른 연결 설정으로 연결되므로 불필요한 오버헤드가 발생할 수 있습니다. (브라우저의 표준 HTTP 요청 분석)

프록시 서버 도구를 확인하여 연결 유지

44단계 요청이 몇 개나 됩니까? 브라우저에서 표준 HTTP 요청 분석을 수행합니다.
46단계 요청 수 감소
  1. 리소스 연결(이미지, CSS 스프라이트, JSON 등)
  2. Clientlibs 포함:
    1. 클라이언트 라이브러리 폴더 만들기 - 임베드를 사용하여 요청 최소화 머리글 참조
48단계 페이로드 크기가 어떻게 됩니까? 브라우저의 표준 HTTP 요청 분석
단계 50 및 51 JS 코드 차단 https://docs.adobe.com/ddc/en/gems/aem-web-performance.html

이 페이지에서는