아래 다이어그램은 성능 문제를 해결하기 위해 수행해야 하는 단계에 대한 지침을 제공하기 위한 것입니다. 그것은 읽기 쉽도록 5개의 부분으로 나뉘어 있다.
다이어그램의 각 단계는 설명서 리소스 또는 권장 사항에 연결됩니다.
성능 문제가 지정된 페이지(AEM 콘솔 또는 웹 페이지)에서 관찰되고 일관되게 재현될 수 있다고 가정합니다. 조사를 시작하기 전에 성능을 테스트하거나 모니터링할 수 있는 방법이 반드시 필요합니다.
분석은 0단계에서 시작됩니다. 목표는 성능 문제를 담당하는 개체(디스패처, 외부 호스트 또는 AEM)을 결정한 다음 어떤 영역(서버 또는 네트워크)을 조사해야 하는지를 결정하는 것입니다.
단계 | 제목 | 리소스 |
0단계 | 요청 흐름 분석 | 브라우저에서 표준 HTTP 요청 분석을 사용하여 요청 흐름을 분석할 수 있습니다. Chrome에서 이 작업을 수행하는 방법에 대한 자세한 내용은 https://developers.google.com/web/tools/chrome-devtools/profile/network-performance/resource- |
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단계 | 느린 요청 찾기 |
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단계 | 메모리가 부족합니다. | |
21단계 | 디스크 I/O | 모니터링 및 유지 관리 설명서의 디스크 I/O 섹션을 참조하십시오. |
단계 22 및 22.1 | 캐시 비율 | 디스패처 캐시 비율 계산. 참조 |
23단계 | 느린 쿼리 | 쿼리 및 색인화에 대한 우수 사례 |
24단계 | 저장소 조정 | |
25단계 | 실행 중인 워크플로우 |
|
26단계 | MSM 인프라 | |
27단계 | 자산 조정 |
|
28단계 | 닫히지 않은 세션 |
|
30단계 | 디스패처를 더 가깝게 이동("지역"당 하나 추가) | |
31단계 | 발송자 앞에 CDN 사용 | CDN에 Dispatcher 사용 |
32단계 | 디스패처 수준에서 세션 관리를 사용하여 AEM 서버 오프로드 | |
33단계 | 요청 액세스 가능 |
캐시 비율을 개선하는 방법;요청 캐시 사용(Dispatcher 우수 사례) 또한 캐싱 구성을 최적화하기 위해 아래 설정을 고려하십시오
|
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 | 살아 유지 | 연결을 다시 사용하기 위해 프록시 서버 도구를 확인하여 연결 유지 |
44단계 | 요청이 몇 개나 됩니까? | 브라우저에서 표준 HTTP 요청 분석을 수행합니다. |
46단계 | 요청 수 감소 |
|
48단계 | 페이로드 크기가 어떻게 됩니까? | 브라우저의 표준 HTTP 요청 분석 |
단계 50 및 51 | JS 코드 차단 | https://docs.adobe.com/ddc/en/gems/aem-web-performance.html |