설명서

Dispatcher 캐시를 최적화하는 방법

Last update: Tue Jul 16 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

이 문서에서는 Dispatcher 캐시를 최적화하는 다양한 방법에 대한 자세한 지침을 제공합니다. 또한 TTL("Time to Live" 또는 만료) 스타일 무효화, Dispatcher 플러시 에이전트 비활성화, Dispatcher 플러시 다시 가져오기 등의 단계에 대해 설명합니다.

설명 description

환경

Adobe Experience Manager

문제/증상

이 문서에서는 AEM Dispatcher의 최신 최적화와 이를 최대한 활용하는 방법에 중점을 둡니다. AEM Dispatcher은 Adobe Experience Manager에서 사용하도록 설계된 캐싱 역방향 프록시 서버입니다. 기존 웹 서버 소프트웨어 내에 모듈로 설치되고 실행될 수 있습니다. 이 문서를 작성할 때 Apache HTTP Server, Microsoft IIS 및 iPlanet에서 Dispatcher 모듈이 지원됩니다.

해결 방법 resolution

Dispatcher 캐싱은 어떻게 작동합니까?

가장 기본적인 수준에서 AEM Dispatcher는 캐싱, 캐시 플러시 및 캐시 무효화를 수행하면서 작동하는 역방향 프록시입니다.

Dispatcher에 대한 자세한 내용은 관련 링크를 참조하십시오.

  1. Dispatcher 작동 방식과 설치 방법.
  2. Dispatcher에서 사용 가능한 구성 옵션.
  3. Dispatcher 작동 방식에 대한 웨비나 - 프레젠테이션의 일부 정보는 이전 버전의 Dispatcher를 기반으로 합니다.
  4. Dispatcher 기능, CDN 사용 및 보안에 대한 Gems 웨비나 세션.
  5. Dispatcher의 새로운 기능에 대한 Gems 세션(v4.1.9 이후).

Dispatcher 캐시 최적화

다음은 Dispatcher 캐시를 최적화하는 몇 가지 방법입니다.

  1. 거의 모든 콘텐츠 캐시하기 - 사용자가 두 번 이상 요청한 콘텐츠를 캐시합니다.

  2. 서로 다른 기간에 개인화된 콘텐츠 캐시하기 - 사이트에 개인화된 콘텐츠가 있는 경우 AEM 애플리케이션에서 Apache Sling Dynamic Includes를 사용하여 Ajax(브라우저 수준의 비동기 JavaScript 및 XML 호출), SSI(웹 서버 수준의 서버측 포함) 및 ESI(CDN 수준의 Edge 측 포함)를 활용하여 서로 다른 기간에 페이지의 다른 부분을 캐시하는 것을 고려하십시오.

  3. 라이브 Dispatcher에서 Dispatcher 캐시를 삭제하지 않음 - Dispatcher에서 라이브 콘텐츠를 제공하고 있는데 캐시를 삭제하면 대량의 요청이 AEM으로 돌아갑니다.  이로 인해 Dispatcher 캐시는 라이브 Dispatcher에서 삭제되면 안 됩니다.

  4. 캐시 준비하기 - Dispatcher 캐시를 삭제하기 전에 로드 밸런서에서 Dispatcher을 당겨 캐시를 삭제한 다음 웹 크롤러 도구를 실행하여 파일을 로드 밸런서에 삽입하기 전에 Dispatcher에서 캐시합니다.

  5. 오류 페이지 캐시하기 - DispatcherPassError 1 (Apache 웹 서버 특정) 지시문을 활용하여 Dispatcher 캐시에서 404와 같은 오류 페이지를 제공합니다.

  6. GZip으로 미리 압축된 파일 형식을 제외한 모든 파일 형식 압축하기 - Apache 웹 서버에서 mod_deflate을(를) 사용할 수 있지만 Vary: 사용자 에이전트 헤더 이(가) 설정되지 않았는지 확인하십시오.  Microsoft IIS에서 동적 압축을 사용합니다.

    Apache 구성 예제(파일 형식이 미리 압축되지 않도록 특정 콘텐츠 유형만 지정):

    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript

  7. /cache 구성에서 /serveStaleOnError 을(를) 사용합니다 - AEM 인스턴스가 오류를 제공할 때 이전 캐시 파일을 제공합니다.

  8. /cache 구성에 /gracePeriod 추가 - 마지막 콘텐츠 게시 이벤트("활성화") 후 캐시에서 오래된 자동 무효화 리소스가 계속 제공될 수 있는 시간(초)을 정의합니다.  이렇게 하면 “트리 활성화”와 같은 대규모 콘텐츠 게시 활동 중에 게시 인스턴스로 돌아가는 요청 개수가 줄어들 수 있습니다.

  9. /ignoreUrlParams 에 규칙 추가 - 응용 프로그램에서 필요하지 않거나 사용하지 않는 쿼리 문자열 매개 변수는 무시합니다.  이를 통해 쿼리 문자열이 있는 경우에도 URL을 캐시할 수 있습니다.

  10. 캐시 제어 및 마지막으로 수정한 응답 헤더 캐시하기 - /headers 구성을 사용하여 HTTP 응답 헤더 캐시 제어 및 마지막으로 수정한 (및/또는 AEM에서 보내는 경우 ETag 헤더 캐시하기).  CDN 및 브라우저 수준에서 캐싱을 간소화하고 최적화하는 데 도움이 됩니다.  이러한 헤더를 캐시하는 경우 웹 서버 자체가 아니라 AEM만 헤더를 설정합니다.  이렇게 하면 AEM 애플리케이션에서 헤더 전송을 시작해야 합니다.

  11. 가능한 한 오래 콘텐츠 캐시하기 및 AEM으로 돌아가는 요청 줄이기 - 플러시 에이전트의 리페칭 플러시를 활성화하여 플러시 요청을 최적화합니다. Dispatcher 플러시 다시 가져오기 ​라는 아래 섹션을 참조하십시오. 또는 /enableTTL 을 사용하고 파일을 가능한 한 오래 캐싱하도록 Cache-Control: max-age=… 헤더를 설정하십시오.  이 항목에 대한 자세한 내용은 아래를 참조하십시오.

TTL 사용

Dispatcher 버전 4.1.11부터 모든 파일 구성에서 /enableTTL 1을 설정할 수 있습니다.  이 설정을 사용하면 Dispatcher에서 HTTP Cache-Control 응답 헤더에 설정된 캐시 만료를 준수합니다.  즉, Dispatcher은 파일이 만료될 때 기본 캐시 무효화 형태가 발생하는 CDN과 유사하게 작동합니다.  이를 구현하고 Cache-Control: max-age= 전송을 시작하면…  AEM의 모든 응답에 대해 게시 인스턴스에서 Dispatcher 플러시 에이전트를 안전하게 비활성화할 수 있습니다.

게시 인스턴스에서 플러시 에이전트를 비활성화한 후에도 Dispatcher 캐시를 플러시할 수 있습니다.  이 경우 ACS Commons - Dispatcher 플러시 UI를 사용할 수 있습니다.  이 도구는 작성자 인스턴스에 설치됩니다.  수동 캐시 플러시 요청을 수행할 수 있는 UI가 사용자에게 제공됩니다.

I. TTL(“Time to Live” 또는 만료) 스타일 무효화를 활성화하는 단계:

  1. AEM 응용 프로그램에서 소스 코드를 수정하여 아직 설정되지 않은 모든 요청에 대해 Cache-Control 헤더 및 마지막으로 수정된 을(를) 보냅니다.
  2. Dispatcher 4.1.11 이상을 설치합니다.
  3. 사이트의 팜 구성에 /enableTTL 1 을(를) 설정합니다.
  4. Cache-Control 및 Last-Modified 헤더를 캐시하도록 /headers 구성을 설정하십시오.
  5. 웹 서버를 다시 시작합니다.

II. 게시 인스턴스 에서 Dispatcher 플러시 에이전트 비활성화

이제 Dispatcher은 Cache-Control 헤더를 사용하여 캐시 파일 무효화를 제어합니다.  이 경우 게시 인스턴스에서 Dispatcher을 플러시할 필요가 없습니다.

  1. 각 게시 인스턴스의 /etc/replication/agents.publish.html로 이동합니다.
  2. 각 플러시 에이전트의 구성으로 이동하고 에이전트를 비활성화합니다.

III. 작성자 인스턴스 에서 수동 Dispatcher 플러시 요청 허용

플러시 에이전트가 비활성화되었으므로 Cache-Control 헤더에 전적으로 의존하여 Dispatcher에서 콘텐츠가 새로 고쳐지는 시기를 제어합니다.  사용자가 Dispatcher 캐시의 수동 플러시를 계속 발행하도록 할 수 있습니다.

  1. 작성자 인스턴스에 ACS Commons - Dispatcher 플러시 UI를 설치합니다.
  2. 작성자 인스턴스에서 플러시 에이전트를 구성합니다.
  3. 각 에이전트 구성에서 트리거 =>를 설정합니다.   기본 옵션 무시 기능을 사용하도록 설정했습니다. 이 옵션을 사용하여 사용자가 AEM UI에서 (게시 취소)게시 또는 (비)활성화 를 클릭하면 플러시 에이전트가 무시됩니다.

Dispatcher 플러시 다시 가져오기

Dispatcher 플러시 요청을 최적화하려면 모든 Dispatcher 플러시 에이전트에서 플러시 다시 가져오기 기능을 활성화해야 합니다.

Dispatcher 플러시 다시 가져오기를 활성화하려면 다음 작업을 수행하십시오.

  1. http://aemhost:port/crx/packmgr/index.jsp 로 이동한 다음 관리자로 로그인합니다.

  2. 여기에서 패키지를 다운로드합니다.

  3. 패키지를 패키지 관리자에 업로드하고 설치합니다.

  4. Dispatcher 플러시 에이전트 구성으로 이동합니다. 예: /etc/replication/agents.author/flush.html

  5. 편집 을 클릭합니다

  6. 다음 참조

    • 직렬화 유형  =  Dispatcher 플러시 다시 가져오기
    • 확장 =>   HTTP 메서드 = POST

  7. 저장 클릭

참고 - 위에 설치된 패키지는 기본 예제일 뿐입니다.  다시 가져오기 플러시를 사용자 정의 및 최적화하려면 보내는 URI 목록을 수정해야 합니다.  코드는 오픈 소스이며 여기에서 찾을 수 있습니다.  이 코드는 요청 본문에 URI 목록을 다시 가져올 경로를 Dispatcher에 알려 주는 매개 변수로 추가합니다.  애플리케이션 요구 사항에 따라 더 많은 경로를 추가하여 사이트의 캐싱 기능을 최적화할 수 있습니다.

다시 가져오기 플러시에 대한 자세한 설명

일반적으로 Dispatcher 플러시는 다음 파일을 삭제하면 작동합니다.

  1. .stat 파일 터치
  2. /content/foo를 삭제합니다.*
  3. /content/foo/_jcr_content 삭제

다음에 사용자가 /content/foo.html 또는 /content/foo.json 같은 파일을 요청할 때 2단계에서 파일이 삭제되므로 파일을 "다시 가져오는" 동안 동일한 파일에 대한 후속 요청이 파일이 캐시될 때까지 게시 인스턴스로 전송되기도 합니다.  응답이 늦거나 홈 페이지 등 트래픽 페이지가 많은 경우 게시 인스턴스 계층이 초과될 수 있습니다.

이 문제를 해결하려면 다시 가져오기 Dispatcher 기능을 활성화합니다.  이 기능을 사용하면 Dispatcher에서 미리 "다시 가져오기"하고 삭제하는 대신 교체해야 하는 URI 목록을 보낼 수 있습니다.

프레젠테이션을 작동 및 구성하는 방식에 대한 데모 버전을 보려면 이 프레젠테이션 녹화본의 22:41-27:05를 참조하십시오.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f