성능 최적화

노트

성능에 대한 일반적인 지침은 성능 지침 페이지를 참조하십시오.

성능 문제 해결 및 수정에 대한 자세한 내용은 성능 트리를 참조하십시오.

또한 성능 조정 팁에 대한 기술 자료 문서를 검토할 수 있습니다.

주요 문제는 웹 사이트가 방문자 요청에 응답하는 시간입니다. 이 값은 각 요청에 따라 다르지만 평균 타겟 값을 정의할 수 있습니다. 이 값이 달성 가능하고 유지 관리할 수 있는 것으로 확인되면 웹 사이트의 성능을 모니터링하고 잠재적 문제의 개발을 나타내는 데 사용할 수 있습니다.

타깃팅할 응답 시간은 대상 대상의 다양한 특성을 반영하여 작성 및 게시 환경에 따라 다릅니다.

작성 환경

이 환경은 컨텐츠 입력 및 업데이트에 의해 사용됩니다. 컨텐츠 페이지 및 해당 페이지의 개별 요소를 업데이트할 때 높은 성능 중심 요청을 생성하는 소수의 사용자를 대상으로 해야 합니다.

게시 환경

이 환경에는 사용자가 사용할 수 있도록 만든 콘텐트가 포함되어 있습니다. 요청 수가 훨씬 많고 속도도 매우 중요하지만 요청의 특성이 덜 동적이므로 추가적인 성능 향상 메커니즘을 적용할 수 있습니다.컨텐츠 캐싱 또는 로드 밸런싱 등의 작업을 수행합니다.

노트

성능 최적화 방법론

AEM 프로젝트에 대한 성능 최적화 방법론은 처음부터 성능 문제를 방지하기 위해 따를 수 있는 매우 간단한 5가지 규칙으로 요약할 수 있습니다.

  1. 최적화 계획
  2. 현실 시뮬레이션
  3. 확고한 목표 설정
  4. 연관성 유지
  5. 민첩한 반복 주기

이러한 규칙은 웹 프로젝트에 일반적으로 적용되며 프로젝트 관리자 및 시스템 관리자와 관련되어 실행 시간이 되면 프로젝트 진행 시 성능 문제가 발생하지 않도록 합니다.

최적화 계획

chlimage_1-3

프로젝트 노력의 약 10%는 성능 최적화 단계를 위해 계획되어야 합니다. 물론 실제 성능 최적화 요구 사항은 프로젝트의 복잡도 수준과 개발 팀의 경험에 따라 다릅니다. 프로젝트가 할당된 시간 전부를 필요로 하지 않지만(궁극적으로) 제안된 영역에서 항상 성능 최적화를 계획하는 것이 좋습니다.

가능하면 실제 경험을 수집하고 추가적인 공지 부담 없이 최적화를 수행하기 위해 제한된 고객을 대상으로 프로젝트를 먼저 소프트 런칭해야 합니다.

"라이브"를 수행하면 성능 최적화는 종료되지 않습니다. 이 시점은 시스템에서 "실제" 로드를 경험할 때 발생합니다. 출시 후에 추가 조정을 계획하는 것이 중요합니다.

시스템 로드가 변경되고 시스템의 성능 프로필이 시간이 지남에 따라 변화하므로 성능 "조정" 또는 "상태 확인"을 6-12개월 간격으로 예약해야 합니다.

현실 시뮬레이션

chlimage_1-4

웹 사이트를 라이브하여 실행한 후 성능 문제가 발생하는 경우를 알 수 있는 이유는 단 한 가지뿐입니다.부하 및 성능 테스트가 현실을 충분히 시뮬레이션하지 못했습니다.

현실을 시뮬레이션하는 것은 어렵고 "실제"에 투자하려는 합리적으로 얼마나 많은 노력이 프로젝트의 성격에 따라 달라집니다. "실제"란 "실제 코드"와 "실제 트래픽"뿐만 아니라 "실제 컨텐트"를 의미하며, 특히 컨텐츠 크기 및 구조에 대해서도 마찬가지입니다. 저장소의 크기와 구조에 따라 템플릿이 완전히 다르게 동작할 수 있습니다.

실선 목표 설정

chlimage_1-5

성능 목표를 제대로 세우는 것의 중요성은 간과할 수 없다. 종종, 사람들이 특정한 실적 목표에 집중하게 되면, 비록 그들이 야생적인 가정을 바탕으로 한다고 할지라도, 그 이후에 이러한 목표를 변경하는 것은 매우 어렵습니다.

좋은, 탄탄한 실적 목표를 세우는 것은 정말로 가장 다루기 힘든 영역 중 하나입니다. 비교 가능한 웹 사이트에서 실제 로그 및 벤치마크를 수집하는 것이 좋습니다(예: 새 웹 사이트의 이전 버전).

연관성 유지

chlimage_1-6

한 번에 하나의 병목 현상을 최적화하는 것이 중요합니다. 하나의 최적화의 효과를 검증하지 않고 동시에 작업을 수행하려고 하면 어느 최적화 측정이 실제로 도움이 되었는지 추적할 수 없게 됩니다.

민첩한 반복 주기

chlimage_1-7

성능 조정은 목표에 도달할 때까지 측정, 분석, 최적화 및 검증을 수행하는 반복적인 프로세스입니다. 이러한 측면을 적절히 고려하려면 각 반복 후에 더 무거운 테스트 프로세스가 아니라 최적화 단계에서 민첩한 유효성 검사 프로세스를 구현합니다.

이는 일반적으로 최적화를 구현하는 개발자가 최적화가 이미 목표에 도달했는지 빨리 알 수 있는 방법을 가져야 한다는 것을 의미합니다. 목표에 도달하면 최적화가 종료되기 때문에 중요한 정보입니다.

기본 성능 지침

일반적으로, 캐시되지 않은 html 요청을 100ms 이하로 유지합니다. 더욱 구체적으로 말하면 다음 사항이 지침으로 제공될 수 있습니다.

  • 페이지 요청의 70%는 100ms 이내에 응답해야 합니다.
  • 페이지 요청의 25%는 100ms-300ms 이내에 응답을 받아야 합니다.
  • 페이지 요청의 4%는 300ms-500ms 이내에 응답을 받아야 합니다.
  • 페이지 요청의 1%는 500ms-1000ms 이내에 응답을 받아야 합니다.
  • 어떤 페이지도 1초보다 느리게 응답해야 합니다.

위의 숫자는 다음 조건을 가정합니다.

  • 게시 시 측정됨(제작 환경과 관련된 오버헤드는 없음)
  • 서버에서 측정됨(네트워크 오버헤드 없음)
  • 캐시되지 않음(AEM 출력 캐시 없음, Dispatcher 캐시 없음)
  • 종속성이 많은 복잡한 항목만(HTML, JS, PDF, …)
  • 시스템에 다른 로드 없음

성능 문제에 자주 영향을 주는 문제가 있습니다. 이러한 주요 회전은 다음과 같습니다.

  • 발송자 캐싱 비효율성
  • 일반 표시 템플릿에서 쿼리 사용

JVM 및 OS 레벨 조정은 일반적으로 성능이 크게 향상되지 않으므로 최적화 주기의 마지막 부분에서 수행해야 합니다.

콘텐츠 저장소를 구성하는 방식도 성능에 영향을 줄 수 있습니다. 최상의 성능을 위해 콘텐츠 저장소의 개별 노드에 연결된 하위 노드의 수는 1,000개를 초과할 수 없습니다(일반 규칙).

평소의 성능 최적화 운동 중 가장 친한 친구는 다음과 같습니다.

  • request.log
  • 구성 요소 기반 시간 설정
  • 마지막으로 자바 프로파일러(Java profiler)가 아닙니다.

디지털 자산을 로드하고 편집할 때의 성능

디지털 자산을 로드하고 편집할 때 많은 양의 데이터가 포함되기 때문에 성능이 문제가 될 수 있습니다.

두 가지 사항이 성능에 영향을 줍니다.

  • CPU - 여러 코어를 사용하여 트랜스코딩할 때 보다 매끄러운 작업 수행
  • 하드 디스크 - 병렬 RAID 디스크가 동일

성능을 개선하려면 다음을 고려하십시오.

  • 하루에 몇 개의 자산을 업로드합니까? 적절한 추정은 다음을 기반으로 할 수 있습니다.

chlimage_1-77

  • 편집할 기간(일반적으로 작업일의 길이, 국제 작업의 경우 더 많음).
  • 업로드된 이미지의 평균 크기(및 이미지당 생성된 표현물의 크기)(MB)입니다.
  • 평균 데이터 전송률을 결정합니다.

chlimage_1-78

  • 모든 편집의 80%는 20% 후에 적용되므로 가장 높은 시간에 평균 데이터 전송률의 4배를 사용하게 됩니다. 이것이 목표 달성의 목표입니다.

성능 모니터링

성능(또는 그 부족)은 사용자가 가장 먼저 인식하는 것 중 하나이며, 사용자 인터페이스가 있는 애플리케이션과 마찬가지로 성능이 중요한 요소입니다. AEM 설치 성능을 최적화하려면 인스턴스와 해당 비헤이비어의 다양한 속성을 모니터링해야 합니다.

성능 모니터링 수행 방법에 대한 자세한 내용은 성능 모니터링을 참조하십시오.

성능 문제를 일으키는 문제는 효과가 쉽게 확인될 때도 추적하기가 어려운 경우가 많습니다.

기본 시작점은 시스템이 정상일 때 잘 알고 있다는 것입니다. 환경이 제대로 작동할 때 어떻게 보이고 동작하는지 모르면 성능이 저하될 때 이 문제를 찾기는 어려울 수 있다. 즉, 시스템이 매끄럽게 실행될 때 시스템을 조사하면서 성능 정보 수집이 진행 중인 작업인지 확인해야 합니다. 그러면 성능이 저하될 경우 비교를 위한 기반을 제공할 수 있습니다.

다음 다이어그램은 AEM 컨텐츠 요청에 사용할 수 있는 경로와 성능에 영향을 줄 수 있는 여러 요소의 수를 보여 줍니다.

chlimage_1-79

성능은 볼륨과 용량 간의 균형 측면이기도 합니다.

  • 볼륨 - 시스템에서 처리 및 전달되는 출력물입니다.
  • 용량 - 볼륨을 전달하는 시스템의 능력입니다.

이 도표는 웹 체인 전체의 다양한 위치에 나타낼 수 있습니다.

chlimage_1-80

성능에 영향을 주는 몇 가지 기능 영역이 있습니다.

  • 캐싱
  • 애플리케이션(프로젝트) 코드
  • 검색 기능

성능관련 기본 규칙

성능을 최적화할 때 특정 규칙을 고려해야 합니다.

  • 성능 조정 은(는) 모든 프로젝트의 일부여야 합니다.
  • 개발 주기 초기에 최적화하지 마십시오.
  • 성능은 가장 약한 링크만큼 좋을 뿐이다.
  • 용량 대 볼륨 모두 항상 고려해야 합니다.
  • 중요한 요소를 먼저 최적화합니다.
  • 사실적인 목표 없이는 최적화하지 마십시오.
노트

성능을 측정하는 데 사용하는 메커니즘은 종종 측정하려는 대상에 영향을 줄 수 있습니다. 여러분은 항상 이러한 불일치를 고려하도록 노력해야 하고, 가능한 한 그 효과의 대부분을 없애야 한다.특정 브라우저 플러그인에서 가능한 한 비활성화해야 합니다.

성능 구성

AEM(및/또는 기본 저장소)의 특정 측면을 성능 최적화를 위해 구성할 수 있습니다. 다음은 가능성과 제안입니다. 변경하기 전에 해당 기능을 사용하는지, 아니면 어떻게 사용하는지 확인해야 합니다.

노트

자세한 내용은 KB 문서를 참조하십시오.

검색 인덱싱

AEM 6.0부터 Adobe Experience Manager은 Oak 기반 저장소 아키텍처를 사용합니다.

업데이트된 색인 정보는 다음 사이트에서 찾을 수 있습니다.

동시 워크플로 처리

동시에 실행 중인 워크플로우 프로세스의 수를 제한하여 성능을 향상시킵니다. 기본적으로 워크플로우 엔진은 Java VM에 사용할 수 있는 프로세서만큼 여러 개의 워크플로우를 동시에 처리합니다. 작업 과정 단계에서 많은 양의 처리 리소스(RAM 또는 CPU)가 필요할 경우 이러한 워크플로우 중 여러 가지를 동시에 실행하면 사용 가능한 서버 리소스에 대한 높은 수요가 발생할 수 있습니다.

예를 들어 이미지(또는 일반적으로 DAM 자산)가 업로드되면 워크플로우에서 이미지를 DAM으로 자동으로 가져옵니다. 이미지는 고해상도로 종종 처리되므로 수백 MB의 힙을 손쉽게 사용할 수 있습니다. 이러한 이미지를 동시에 처리하면 메모리 하위 시스템 및 가비지 수집기에 높은 로드가 발생합니다.

워크플로 엔진은 작업 항목 처리를 처리하고 예약하기 위해 Apache Sling 작업 대기열을 사용합니다. 다음 작업 큐 서비스는 처리 워크플로 작업을 위해 Apache Sling 작업 큐 구성 서비스 팩터리에서 기본적으로 만들어졌습니다.

  • Granite Workflow Queue:DAM 자산을 처리하는 것과 같은 대부분의 워크플로우 단계는 Granite Workflow Queue 서비스를 사용합니다.
  • Granite Workflow 외부 프로세스 작업 큐:이 서비스는 일반적으로 외부 시스템에 연결하고 결과를 폴링하는 데 사용되는 특수 외부 워크플로우 단계에 사용됩니다. 예를 들어 InDesign 미디어 추출 프로세스 단계는 외부 프로세스로 구현됩니다. 워크플로 엔진은 폴링을 처리하기 위해 외부 큐를 사용합니다. (com.day.cq.workflow.exec.WorkflowExternalProcess 참조)

동시에 실행 중인 워크플로 프로세스의 최대 수를 제한하도록 이 서비스를 구성합니다.

노트

특정 워크플로우 모델에 대한 작업 큐를 만들지 않으면 이러한 작업 대기열을 구성하면 모든 워크플로우에 영향을 줍니다(아래 특정 워크플로우 모델에 대한 대기열 구성 참조).

저장소의 구성

sling:OsgiConfig 노드](/docs/experience-manager-65/deploying/configuring/configuring-osgi.html?lang=ko#adding-a-new-configuration-to-the-repository)을 사용하여 서비스 [를 구성하는 경우 기존 서비스의 PID를 찾아야 합니다. 예:org.apache.sling.event.jobs.QueueConfiguration.370aad73-d01b-4a0b-abe4-20198d85f705. 웹 콘솔을 사용하여 PID를 검색할 수 있습니다.

queue.maxparallel 속성을 구성해야 합니다.

웹 콘솔의 구성

웹 콘솔](/docs/experience-manager-65/deploying/configuring/configuring-osgi.html?lang=ko#osgi-configuration-with-the-web-console)을 사용하여 이러한 서비스 [를 구성하려면 Apache Sling 작업 큐 구성 서비스 팩토리 아래에서 기존 구성 항목을 찾습니다.

최대 병렬 작업이라는 속성을 구성해야 합니다.

특정 작업 과정에 대한 큐 구성

해당 워크플로우 모델에 대한 작업 처리를 구성할 수 있도록 특정 워크플로우 모델에 대한 작업 큐를 만듭니다. 이러한 방식으로 구성은 특정 작업 과정의 처리에 영향을 주고 기본 [Granite Workflow 큐]의 구성은 다른 작업 과정의 처리를 제어합니다.

워크플로우 모델이 실행되면 특정 주제에 대한 Sling 작업이 만들어집니다. 기본적으로 이 항목은 일반 Granite Workflow Queue 또는 Granite Workflow 외부 프로세스 작업 큐에 대해 구성된 항목과 일치합니다.

  • com/adobe/granite/workflow/job*
  • com/adobe/granite/workflow/external/job*

워크플로우 모델이 생성하는 실제 작업 항목에는 모델별 접미사 사용이 포함됩니다. 예를 들어 DAM 자산 업데이트 워크플로우 모델은 다음 항목으로 작업을 생성합니다.

com/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/model

따라서 워크플로우 모델의 작업 항목과 일치하는 항목에 대한 작업 큐를 만들 수 있습니다. 대기열의 성능 관련 속성을 구성하면 대기열 항목과 일치하는 작업을 생성하는 워크플로우 모델에만 영향을 줍니다.

다음 절차에서는 DAM 자산 업데이트 작업 과정을 예로 사용하여 워크플로우에 대한 작업 큐를 만듭니다.

  1. 주제 통계가 생성되도록 작업 대기열을 만들 워크플로우 모델을 실행합니다. 예를 들어 이미지를 자산에 추가하여 DAM 자산 업데이트 작업 과정을 실행합니다.

  2. Sling 작업 콘솔(https://<host>:<port>/system/console/slingevent)을 엽니다.

  3. 콘솔에서 워크플로우 관련 항목을 알아봅니다. DAM Update Asset의 경우 다음 항목을 찾을 수 있습니다.

    • com/adobe/granite/workflow/external/job/etc/workflow/models/dam/update_asset/jcr_content/model
    • com/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/model
    • com/adobe/granite/workflow/job/etc/workflow/models/dam-xmp-writeback/jcr_content/model
  4. 각 항목에 대해 하나의 작업 큐를 만듭니다. 작업 큐를 만들려면 Apache Sling 작업 큐 팩토리 서비스에 대한 팩토리 구성을 만듭니다.

    팩토리 구성은 작업 과정 작업의 항목과 일치한다는 점을 제외하고 동시 워크플로 처리에 설명된 [화강암 워크플로 큐]와 유사합니다.

AEM DAM 자산 동기화 서비스

AssetSynchronizationService은 마운트된 저장소(LiveLink, Documentum 등)의 자산을 동기화하는 데 사용됩니다. 기본적으로 300초(5분)마다 정기적으로 확인되므로 마운트된 저장소를 사용하지 않으면 이 서비스를 비활성화할 수 있습니다.

이 작업은 OSGi 서비스 CQ DAM 자산 동기화 서비스​를 구성하여 동기화 기간( scheduler.period)을 1년(초 단위로 정의됨)으로 설정합니다.

여러 DAM 인스턴스

예를 들어 여러 DAM 인스턴스를 배포하면 성능을 향상시킬 수 있습니다.

  • 작성 환경에 대한 많은 자산의 정기적인 업로드로 인해 로드가 높습니다.여기에서 별도의 DAM 인스턴스를 작성자 서비스 전용으로 지정할 수 있습니다.
  • 전 세계 지역(예: 미국, 유럽, 아시아)에 여러 팀이 있습니다.

추가 고려 사항은 다음과 같습니다.

  • 게시 시 "진행 중인 작업"과 "최종" 구분
  • 작성자의 내부 사용자를 외부 방문자/게시물의 사용자와 구분(예: 에이전트, 보도 담당자, 고객, 학생 등)

품질 보증 우수 사례

게시 환경에 가장 중요한 것은 성능입니다. 따라서 프로젝트를 구현하는 동안 게시 환경에 대해 수행하는 성능 테스트를 신중하게 계획하고 분석해야 합니다.

이 섹션에서는 publish 환경에서 성능 테스트를 위한 테스트 개념을 정의하는 것과 관련된 문제에 대한 표준화된 개요를 제공하기 위해 마련되었습니다. 이는 주로 QA 엔지니어, 프로젝트 관리자 및 시스템 관리자에게 도움이 됩니다.

다음은 게시 환경에서 AEM 응용 프로그램의 성능 테스트에 대한 표준화된 접근 방식을 설명합니다. 여기에는 다음 5단계가 포함됩니다.

제어란 테스트에 한정되지 않고, 모두를 통합시키는 추가 프로세스입니다.

지식 확인

첫 번째 단계는 테스트를 시작하기 전에 알아야 하는 기본 정보를 문서화하는 것입니다.

  • 테스트 환경의 아키텍처
  • 테스트를 필요로 하는 내부 요소를 자세히 설명하는 응용 프로그램 맵(격리 및 조합)

테스트 아키텍처

성능 테스트에 사용되는 테스트 환경의 아키텍처를 명확히 문서화해야 합니다.

계획된 제작 게시 환경을 디스패처 및 로드 밸런서와 함께 복제해야 합니다.

응용 프로그램 맵

명확한 개요를 얻으려면 전체 응용 프로그램의 맵을 만들 수 있습니다(작성 환경의 테스트에서 이러한 맵을 얻을 수 있음).

응용 프로그램의 내부 요소를 나타낸 다이어그램 표현에서는 테스트 요구 사항에 대한 개요를 알 수 있습니다.색상 코딩을 사용하면 보고 기반으로 사용할 수도 있습니다.

범위 정의

애플리케이션에는 일반적으로 다양한 사용 사례가 있습니다. 어떤 것은 매우 중요할 것이고, 다른 것들은 덜 중요할 것이다.

게시 시 성능 테스트의 범위에 초점을 맞추려면 다음을 정의하는 것이 좋습니다.

  • 가장 중요한 비즈니스 사용 사례
  • 가장 중요한 기술 사용 사례

사용 사례는 사용자별로 다르지만 관리하기 쉬운 수(예: 5~10 사이)로 제한되어야 합니다.

주요 사용 사례를 선택하면 KPI(Key Performance Indicator) 및 이를 측정하는 데 사용되는 도구를 각 케이스에 대해 정의할 수 있습니다. 일반적인 KPI의 예는 다음과 같습니다.

  • 종료 응답 시간
  • 서블릿 응답 시간
  • 단일 구성 요소에 대한 응답 시간
  • 서비스 응답 시간
  • 스레드 풀의 유휴 스레드 수
  • 무료 연결 수
  • CPU 및 I/O 액세스와 같은 시스템 리소스

테스트 방법론

이 개념이 성능 목표를 정의하고 테스트하는 데 사용되는 4가지 시나리오가 있습니다.

  • 단일 구성 요소 테스트
  • 구성 요소 테스트 결합
  • Going Livescenario
  • 오류 시나리오

다음 원칙을 기반으로 합니다.

구성 요소 중단점

  • 각 구성 요소에는 성능과 관련된 특정 중단점이 있습니다. 즉, 특정 지점에 도달할 때까지 구성 요소의 성능이 향상될 수 있으며 그 후 성능이 빠르게 저하됩니다.
  • 응용 프로그램의 전체 개요를 보려면 먼저 구성 요소를 확인하여 각 중단점에 도달하는 시기를 결정해야 합니다.
  • 중단점을 찾기 위해 일정 기간 동안 로드를 증가시키는 로드 테스트를 수행할 수 있습니다. 이 로드 및 구성 요소의 응답을 모니터링하면 구성 요소의 중단점에 도달할 때 특정 성능 동작이 발생합니다. 이 포인트는 동시 사용자 수(구성 요소가 이 KPI에 민감한 경우) 와 함께 초당 동시 트랜잭션 수로 적격할 수 있습니다.
  • 이러한 정보는 개선 사항의 벤치마크 역할을 할 수 있으며, 사용 중인 측정값의 효율성을 표시하고, 테스트 시나리오를 정의하는 데 도움이 됩니다.

트랜잭션

  • 트랜잭션 용어는 페이지 자체 및 모든 후속 호출을 포함하여 전체 웹 페이지의 요청을 나타내는 데 사용됩니다.페이지 요청, 모든 AJAX 호출, 이미지 및 기타 개체 등​드릴다운 요청
  • 각 요청을 완전히 분석하기 위해 호출 스택의 각 요소를 표시한 다음 각 요청에 대한 평균 처리 시간을 합산할 수 있습니다.

성과 목표 정의

범위 및 관련 KPI가 정의되면 구체적인 성과 목표를 설정할 수 있습니다. 여기에는 대상 값과 함께 테스트 시나리오를 고안하는 작업이 포함됩니다.

평균 및 최대 조건 모두에서 성능을 테스트해야 합니다. 또한 웹 사이트를 처음 사용할 수 있게 되면 웹 사이트에 대한 관심 증가 요구 사항을 충족하기 위해 Go Live 시나리오 테스트가 필요합니다.

기존 웹 사이트에서 수집한 경험 또는 통계도 향후 목표를 결정하는 데 유용합니다.예를 들어 라이브 웹 사이트의 주요 트래픽이 있습니다.

단일 구성 요소 테스트

중요한 구성 요소는 평균 및 최고 조건 모두에서 테스트되어야 합니다.

두 경우 모두 미리 정의된 사용자 수가 시스템을 사용하는 경우 예상되는 초당 트랜잭션 수를 정의할 수 있습니다.

구성 요소 테스트 유형 아니오. 사용자 수 Tx/초(예상) Tx/초(테스트됨) 설명
홈 페이지 단일 사용자 평균 1 1
피크 1 3
홈 페이지 사용자 100명 평균 100 1
피크 100년 1

결합된 구성 요소 테스트

구성 요소를 조합하여 테스트하면 애플리케이션 비헤이비어가 더 자세히 반영됩니다. 다시 평균과 최고점 조건을 테스트해야 합니다.

시나리오 구성 요소 아니오. 사용자 수 Tx/초(예상) Tx/초(테스트됨) 설명
혼합 평균 홈 페이지 10 1
검색 10 1
뉴스 10 2
이벤트 10 1
활동 10 1 작성자 동작 시뮬레이션
혼합 피크 홈 페이지 100년 5
검색 50 5
뉴스 100년 10
이벤트 100년 10
활동 20 20년 작성자 동작 시뮬레이션

라이브 테스트 시작

웹 사이트를 제공한 후 처음 며칠 동안 관심 수준이 높아지기를 예상할 수 있습니다. 이것은 테스트한 최대 값보다 더 클 수 있습니다. 시스템이 이 상황에 맞게 지원할 수 있도록 Go Live 시나리오를 테스트하는 것이 좋습니다.

시나리오 테스트 유형 아니오. 사용자 수 Tx/초(예상) Tx/초(테스트됨) 설명
라이브 피크 홈 페이지 200 20년
검색 100년 10
뉴스 200년 20년
이벤트 200년 20년
활동 20년 20년 작성자 동작 시뮬레이션

오류 시나리오 테스트

또한 시스템이 정확하고 적절하게 반응하도록 오류 시나리오를 테스트해야 합니다. 오류 자체를 처리하는 방법뿐만 아니라 성능에 미치는 영향도 있습니다. 예:

  • 사용자가 검색 상자에 잘못된 검색어를 입력하려고 하면 어떻게 됩니까?
  • 검색어가 너무 일반적이어서 너무 많은 수의 결과를 반환하는 경우

이러한 테스트를 고안할 때, 모든 시나리오가 정기적으로 발생하는 것은 아니라는 것을 기억해야 한다. 하지만, 그들이 전체 시스템에 미치는 영향은 중요하다.

오류 시나리오 오류 유형 아니오. 사용자 수 Tx/초(예상) Tx/초(테스트됨) 설명
검색 구성 요소 오버로드 전역 와일드카드 검색(별표) 10 1 승_only &ast;&ast;&ast;검색됩니다.
중지 단어 20년 2 중지 단어 검색
빈 문자열 10 1 빈 문자열을 검색합니다.
특수 문자 10 1 특수 문자 검색

지구력 테스트

특정 문제는 지속적으로 시스템이 실행된 후에만 발생합니다.그것은 시간 혹은 심지어 날들이다. 지구력 시험은 필요한 기간 동안 일정한 평균 부하를 테스트하는 데 사용됩니다. 그런 다음 성능 저하를 분석할 수 있습니다.

시나리오 테스트 유형 아니오. 사용자 수 Tx/초(예상) Tx/초(테스트됨) 설명
지구력 테스트(72시간) 홈 페이지 10 1
검색 10 1
뉴스 20년 2
이벤트 10 1
활동 1 1 작성자 동작 시뮬레이션

최적화

구현 후 단계에서 성능 목표를 충족하거나 최대화하기 위해 애플리케이션을 최적화해야 합니다.

최적화를 테스트하여 다음을 확인해야 합니다.

  • 기능에 영향을 주지 않음
  • 출시 전에 로드 테스트를 통해 확인됨

로드 생성, 성능 모니터링 및/또는 결과 분석에 도움이 되는 다양한 도구를 사용할 수 있습니다.

최적화 후 효과를 확인하기 위해 다시 테스트해야 합니다.

보고

이전에 색상 코딩에 대해 언급했듯이 현재 상태를 모든 사람에게 알려주는 지속적인 보고가 필요합니다. 아키텍처 맵은 여기에 사용할 수 있습니다.

모든 테스트가 완료되면 다음을 보고할 수 있습니다.

  • 발생한 중요한 오류
  • 더 이상의 조사가 필요할 중요하지 않은 문제
  • 테스트 중에 발생한 모든 가정
  • 테스트에서 발생할 수 있는 모든 권장 사항

Dispatcher사용 시 성능 최적화

Dispatcher은 Adobe의 캐싱 및/또는 로드 밸런싱 도구입니다. 디스패처를 사용할 때는 캐시 성능을 위해 웹 사이트를 최적화하는 것을 고려해야 합니다.

노트

디스패처 버전은 AEM과 독립적이지만, Dispatcher 문서는 AEM 문서에 포함되어 있습니다. 항상 최신 버전의 AEM에 대한 설명서에 포함된 Dispatcher 문서를 사용합니다.

이전 버전의 AEM에 대한 설명서에 포함된 Dispatcher 설명서에 대한 링크를 따라간 경우 이 페이지로 리디렉션되었을 수 있습니다.

Dispatcher는 웹 사이트에서 성능을 활용할 때 성능을 최적화하는 데 사용할 수 있는 다양한 내장 메커니즘을 제공합니다. 이 섹션에서는 캐싱의 이점을 극대화하기 위해 웹 사이트를 디자인하는 방법을 설명합니다.

노트

Dispatcher가 표준 웹 서버에 캐시를 저장한다는 사실을 기억하는 데 도움이 될 수 있습니다. 이는 다음과 같은 의미입니다.

  • 페이지로 저장할 수 있는 모든 것을 캐싱하고 URL을 사용하여 요청할 수 있습니다.
  • 쿠키, 세션 데이터 및 양식 데이터와 같은 다른 항목은 저장할 수 없습니다.

일반적으로 많은 캐싱 전략은 좋은 URL을 선택하는 것과 이 추가 데이터에 의존하지 않는 것입니다.

Dispatcher 버전 4.1.11에서는 응답 헤더를 캐시할 수도 있습니다. HTTP 응답 헤더 캐싱을 참조하십시오.

발송자 캐시 비율 계산 중

캐시 비율 공식은 시스템에 들어오는 총 요청 수 중 캐시에서 처리한 요청의 백분율을 예측합니다. 캐시 비율을 계산하려면 다음을 수행해야 합니다.

  • 총 요청 수입니다. 이 정보는 Apache access.log에서 사용할 수 있습니다. 자세한 내용은 공식 Apache 설명서를 참조하십시오.

  • 게시 인스턴스가 제공된 요청 수입니다. 이 정보는 인스턴스의 request.log에서 사용할 수 있습니다. 자세한 내용은 request.log 해석로그 파일 찾기를 참조하십시오.

캐시 비율을 계산하는 공식은 다음과 같습니다.

  • (총 요청 수 빼기 게시 요청 수) 나누기​는 총 요청 수로 나눈 값입니다.

예를 들어 총 요청 수가 129491이고 게시 인스턴스에서 제공하는 요청 수가 58959이면 캐시 비율은 다음과 같습니다.(129491 - 58959)/129491= 54.5%.

1대1 게시자/디스패처 쌍이 없는 경우 정확한 측정을 얻으려면 모든 디스패처 및 게시자의 요청을 함께 추가해야 합니다. 권장 배포도 참조하십시오.

노트

최상의 성능을 위해 Adobe은 캐시 비율을 90%에서 95%로 권장합니다.

일관된 페이지 인코딩 사용

Dispatcher 버전 4.1.11에서는 응답 헤더를 캐시할 수 있습니다. Dispatcher에서 응답 헤더를 캐싱하지 않는 경우, 헤더에 페이지 인코딩 정보를 저장하는 경우 문제가 발생할 수 있습니다. 이 경우 Dispatcher가 캐시에서 페이지를 서비스하면 웹 서버의 기본 인코딩이 페이지에 사용됩니다. 이 문제를 피하는 두 가지 방법이 있습니다.

  • 인코딩을 하나만 사용할 경우 웹 서버에서 사용되는 인코딩이 AEM 웹 사이트의 기본 인코딩과 동일한지 확인합니다.
  • 다음 예와 같이 HTML head 섹션의 <META> 태그를 사용하여 인코딩을 설정합니다.
        <META http-equiv="Content-Type" content="text/html; charset=EUC-JP">

URL 매개 변수방지

가능하면 캐시하려는 페이지에 대한 URL 매개 변수를 피하십시오. 예를 들어 사진 갤러리가 있는 경우 Dispatcher가 그에 따라 구성된 경우를 제외하고 다음 URL은 캐시되지 않습니다.

www.myCompany.com/pictures/gallery.html?event=christmas&amp;page=1

그러나 다음과 같이 페이지 URL에 이러한 매개 변수를 배치할 수 있습니다.

www.myCompany.com/pictures/gallery.christmas.1.html
노트

이 URL은 gallery.html과 동일한 페이지와 동일한 템플릿을 호출합니다. 템플릿 정의에서 페이지를 렌더링하는 스크립트를 지정하거나 모든 페이지에 동일한 스크립트를 사용할 수 있습니다.

URL로 사용자 지정

사용자가 글꼴 크기(또는 기타 레이아웃 사용자 정의)를 변경할 수 있도록 허용하는 경우 다른 사용자 정의 설정이 URL에 반영되어 있는지 확인합니다.

예를 들어 쿠키는 캐시되지 않으므로 글꼴 크기를 쿠키(또는 유사한 메커니즘)에 저장하는 경우, 캐시된 페이지에 대해서는 글꼴 크기가 유지되지 않습니다. 결과적으로 Dispatcher는 임의의 글꼴 크기의 문서를 반환합니다.

선택기로 URL에 글꼴 크기를 포함하면 다음 문제가 발생하지 않습니다.

www.myCompany.com/news/main.large.html
노트

대부분의 레이아웃 측면에서는 스타일 시트 및/또는 클라이언트측 스크립트를 사용할 수도 있습니다. 이러한 기능은 일반적으로 캐싱 작업에서 매우 잘 작동합니다.

다음과 같은 URL을 사용할 수 있는 인쇄 버전에도 유용합니다.

www.myCompany.com/news/main.print.html

템플릿 정의의 스크립트 글로브를 사용하여 인쇄 페이지를 렌더링하는 별도의 스크립트를 지정할 수 있습니다.

제목으로 사용된 이미지 파일을 무효화합니다.

페이지 제목 또는 다른 텍스트를 그림으로 렌더링하는 경우 페이지의 컨텐츠 업데이트 시 삭제되도록 파일을 저장하는 것이 좋습니다.

  1. 이미지 파일을 페이지와 동일한 폴더에 배치합니다.

  2. 이미지 파일에 다음 이름 지정 형식을 사용합니다.

    <page file name>.<image file name>

예를 들어 myPage.html 페이지의 제목을 file myPage.title.gif에 저장할 수 있습니다. 페이지가 업데이트되면 이 파일은 자동으로 삭제되므로 페이지 제목의 변경 사항은 캐시에 자동으로 반영됩니다.

노트

이미지 파일이 반드시 AEM 인스턴스에 실제로 존재하는 것은 아닙니다. 이미지 파일을 동적으로 만드는 스크립트를 사용할 수 있습니다. 그런 다음 Dispatcher가 웹 서버에 파일을 저장합니다.

탐색에 사용된 이미지 파일을 무효화합니다.

탐색 항목에 사진을 사용하는 경우 이 방법은 기본적으로 제목과 동일하며 약간 더 복잡합니다. 대상 페이지에 모든 탐색 이미지를 저장합니다. 일반 및 활성 이미지를 위해 두 개의 사진을 사용하는 경우 다음 스크립트를 사용할 수 있습니다.

  • 페이지를 보통으로 표시하는 스크립트입니다.
  • ".normal" 요청을 처리하고 일반 그림을 반환하는 스크립트입니다.
  • ".active" 요청을 처리하고 활성화된 사진을 반환하는 스크립트입니다.

페이지와 동일한 이름 지정 핸들을 사용하여 이러한 그림을 만드는 것이 중요합니다. 컨텐츠 업데이트를 통해 페이지 뿐만 아니라 이러한 사진도 삭제할 수 있습니다.

수정되지 않은 페이지의 경우 페이지 자체가 일반적으로 자동으로 무효화되더라도 사진은 여전히 캐시에 남아 있습니다.

개인화

개인화는 필요한 위치로 제한하는 것이 좋습니다. 이유를 설명하기 위해:

  • 자유롭게 사용자 정의 가능한 시작 페이지를 사용하는 경우 사용자가 페이지를 요청할 때마다 해당 페이지를 구성해야 합니다.
  • 반면, 10개의 서로 다른 시작 페이지를 제공하는 경우 각 시작 페이지를 캐시하여 성능을 향상시킬 수 있습니다.

Dispatcher 캐시 구성에 대한 자세한 내용은 AEM Dispatcher Cache Tutorial보호된 컨텐트 캐싱 섹션을 참조하십시오.

제목 표시줄에 사용자 이름을 넣는 등 각 페이지를 개인화하면 성능에 영향을 줄 수 있습니다.

보안 콘텐츠를 캐싱하는 방법은 Dispatcher 안내서의 보안 컨텐츠 캐싱을 참조하십시오.

제한적 컨텐츠와 공개 컨텐츠를 한 페이지에서 믹싱하는 것과 관련하여 Dispatcher의 서버측 포함을 활용하는 전략이나 브라우저에서 Ajax를 통해 클라이언트측 포함을 고려할 수 있습니다.

혼합된 공개 및 제한된 내용을 처리하려면 Sling 동적 포함 설정을 참조하십시오.

고정 연결

고정 연결한 사용자에 대한 문서가 모두 동일한 서버에서 작성되도록 합니다. 사용자가 이 폴더를 나갔다가 나중에 이 폴더로 돌아오면 연결이 계속 유지됩니다. 웹 사이트에 대해 고정 연결이 필요한 모든 문서를 보관할 하나의 폴더를 정의합니다. 다른 문서를 포함하지 마십시오. 이는 개인화된 페이지 및 세션 데이터를 사용하는 경우 로드 밸런싱에 영향을 줍니다.

MIME 유형

브라우저에서 파일 유형을 결정하는 방법에는 두 가지가 있습니다.

  1. 확장(예:.html, .gif, .jpg 등)
  2. 서버가 파일과 함께 보내는 MIME-유형입니다.

대부분의 파일에 대해 MIME 유형은 파일 확장명에 암시되어 있습니다. i.e.:

  1. 확장(예:.html, .gif, .jpg 등)
  2. 서버가 파일과 함께 보내는 MIME-유형입니다.

파일 이름에 확장자가 없으면 일반 텍스트로 표시됩니다.

Dispatcher 버전 4.1.11에서는 응답 헤더를 캐시할 수 있습니다. Dispatcher에서 응답 헤더를 캐시하지 않는 경우 MIME 유형이 HTTP 헤더의 일부임을 인식하십시오. 따라서 AEM 응용 프로그램에서 인식할 수 없는 파일 끝 부분을 반환하고 대신 MIME 형식을 사용하는 경우 이러한 파일이 잘못 표시될 수 있습니다.

파일이 제대로 캐시되는지 확인하려면 다음 지침을 따르십시오.

  • 파일의 확장자가 항상 적절한지 확인합니다.
  • download.jsp?file=2214과 같은 URL이 있는 일반 파일 서버 스크립트를 사용하지 마십시오. 파일 사양을 포함하는 URL을 사용하도록 스크립트를 다시 작성합니다. 이전 예제의 경우 이것은 download.2214.pdf입니다.

백업 성능

이 섹션에서는 AEM 백업 성능 및 백업 작업이 애플리케이션 성능에 미치는 영향을 평가하는 데 사용되는 일련의 벤치마크를 제공합니다. AEM 백업이 실행되는 동안 시스템에 상당한 로드를 표시하므로, 이러한 효과를 수정하려는 백업 지연 설정의 효과뿐만 아니라 이러한 효과를 측정합니다. 이 목표는 실제 구성과 운영 데이터의 수량에 대한 예상 백업 성능에 대한 참조 데이터를 제공하고, 계획된 시스템의 백업 시간을 측정하는 방법에 대한 지침을 제공하는 것입니다.

참조 환경

물리적 시스템

이 문서에서 보고된 결과는 다음과 같은 구성을 가진 참조 환경에서 실행되는 벤치마크로부터 얻습니다. 이 구성은 데이터 센터의 일반적인 제작 환경과 유사하도록 설계되었습니다.

  • H-P ProLiant DL380 G6, 8개의 CPU x 2.533GHz
  • 직렬 연결 SCSI 300GB 10,000RPM 드라이브
  • 하드웨어 RAID 컨트롤러;RAID0+5 어레이의 드라이브 8개
  • VMware 이미지 CPU x 2 Intel Xeon E5540 @ 2.53GHz
  • RedHat Linux 2.6.18-194.el5;Java 1.6.0_29
  • 단일 작성자 인스턴스

이 서버의 디스크 하위 시스템은 제작 서버에서 사용할 수 있는 고성능 RAID 구성을 나타내는 매우 빠른 속도입니다. 백업 성능은 디스크 성능에 영향을 줄 수 있으며 이 환경의 결과는 매우 빠른 RAID 구성에 대한 성능을 반영합니다. VMWare 이미지는 RAID 어레이에 물리적으로 로컬 디스크 스토리지에 있는 단일 대용량 디스크 볼륨을 갖도록 구성되어 있습니다.

AEM 구성은 모든 운영 체제와 AEM 소프트웨어와 함께 저장소 및 데이터 저장소를 동일한 논리 볼륨에 배치합니다. 백업의 대상 디렉토리는 이 논리 파일 시스템에도 있습니다.

데이터 볼륨

다음 표는 백업 벤치마크에서 사용되는 데이터 볼륨의 크기를 보여 줍니다. 초기 기준 컨텐츠가 먼저 설치된 다음, 백업된 컨텐츠의 크기를 늘리기 위해 알려진 추가 데이터 양이 추가됩니다. 컨텐츠의 큰 증가 및 하루 단위로 생성할 수 있는 내용을 나타내기 위해 특정 증분으로 백업을 만듭니다. 컨텐츠(페이지, 이미지, 태그)의 배포는 실제 제작 에셋 구성을 기반으로 대략 이루어집니다. 페이지, 이미지 및 태그는 최대 800개의 하위 페이지로 제한됩니다. 각 페이지에는 제목, Flash, 텍스트/이미지, 비디오, 슬라이드쇼, 양식, 표, 클라우드 및 회전판 구성 요소가 포함됩니다. 이미지는 37kB부터 594kB까지 크기가 다양한 400개의 고유한 파일 풀에서 업로드됩니다.

컨텐트 노드 페이지 이미지 태그
기본 설치 69 610 562년 256년 237년
증분 백업을 위한 작은 컨텐츠 +100 +2 +2
전체 백업용 대용량 컨텐츠 +10 000 +100 +100

백업 벤치마크는 각 반복에 추가 컨텐츠 세트를 추가하여 반복됩니다.

벤치마크 시나리오

백업 벤치마크에는 다음과 같은 두 가지 주요 시나리오가 포함되어 있습니다.시스템이 상당한 애플리케이션 로드에서 백업되고 시스템이 유휴 상태일 때 백업이 수행됩니다. AEM이 가능한 유휴 상태일 때 백업을 수행해야 하지만 시스템이 로드될 때 백업을 실행해야 하는 경우가 있습니다.

  • 유휴 상태 - AEM에서 다른 작업을 수행하지 않고 백업이 수행됩니다.
  • Load - Backups는 시스템이 온라인 프로세스에서 80% 로드가 적은 동안 수행됩니다. 로드가 미치는 영향을 보기 위해 백업 지연이 다양한 방식을 적용했습니다.

백업 시간 및 결과 백업 크기는 AEM 서버 로그에서 가져옵니다. 일반적으로 AEM이 유휴 상태일 때(예: 한밤중) 백업을 비정기적으로 예약하는 것이 좋습니다. 이 시나리오는 권장 접근 방식을 나타냅니다.

Load는 페이지 탐색 및 쿼리에서 나오는 대부분의 로드를 갖는 페이지 만들기/삭제, 탐색 및 쿼리로 구성됩니다. 너무 많은 페이지를 추가 및 제거하면 작업 영역 크기가 지속적으로 증가하고 백업 작업이 완료되지 않습니다. 스크립트가 사용할 로드의 분배는 75% 페이지 순회, 24%의 쿼리 및 1%의 페이지 작성입니다(중첩된 하위 페이지가 없는 단일 수준). 유휴 시스템의 초당 최대 평균 트랜잭션은 4개의 동시 스레드로 달성되며, 이는 백업 로드 중에 테스트를 수행할 때 사용됩니다.

백업 성능에 대한 로드 영향은 이 애플리케이션 로드 여부와 상관없이 성능에 대한 차이에 의해 예측할 수 있습니다. 애플리케이션 처리량에 대한 백업의 영향은 동시 백업이 진행 중인 경우와 없는 경우, 그리고 다른 "백업 지연" 설정으로 작동하는 백업과 동시에 시간당 트랜잭션 처리 시간을 비교하여 찾을 수 있습니다.

  • 지연 설정 - 여러 가지 시나리오의 경우 10ms(기본값), 1ms 및 0ms 값을 사용하여 백업 지연 설정을 변경하여 이 설정이 백업 성능에 어떤 영향을 주는지 살펴봅니다.
  • 백업 유형 - 모든 백업은 zip을 작성하지 않고 백업 디렉토리에 만들어진 저장소의 외부 백업이었습니다. 단, tar 명령을 직접 사용한 경우를 비교할 때는 한 번 였습니다. 증분 백업을 zip 파일로 만들 수 없거나 이전 전체 백업이 zip 파일인 경우 백업 디렉토리 방법이 프로덕션 환경에서 가장 자주 사용됩니다.

결과 요약

백업 시간 및 처리량

이러한 벤치마크의 주요 결과는 백업 유형이 데이터의 전체 양과 같은 기능으로서 백업 시간이 어떻게 달라지는지를 보여줍니다. 다음 차트는 전체 페이지 수의 함수로 기본 백업 구성을 사용하여 얻은 백업 시간을 보여줍니다.

chlimage_1-81

유휴 인스턴스의 백업 시간은 전체 백업 또는 증분 백업에 관계없이 상당히 일관적이며 평균 0.608MB/s입니다(아래 차트 참조). 백업 시간은 단순히 백업되는 데이터의 양의 함수입니다. 전체 백업을 완료하는 데 걸리는 시간은 총 페이지 수에 따라 분명 증가합니다. 증분 백업을 완료하는 시간도 총 페이지 수로 증가하지만 훨씬 낮은 비율로 증가합니다. 백업 중인 데이터의 양이 상대적으로 적기 때문에 증분 백업을 완료하는 데 걸리는 시간이 훨씬 더 짧습니다.

생성된 백업 크기는 백업을 완료하는 데 걸리는 시간을 결정하는 주요 요소입니다. 다음 차트는 최종 백업 크기의 기능으로 수행된 시간을 보여줍니다.

chlimage_1-82

이 차트에서는 증분 및 전체 백업 모두 단순한 크기와 시간 패턴을 따르며 처리량을 측정할 수 있음을 보여줍니다. 유휴 인스턴스의 백업 시간은 벤치마크 환경의 전체 백업 또는 증분 백업에 관계없이 상당히 일관적이며 평균 0.61MB/초 단위입니다.

백업 지연

백업 지연 매개 변수가 제공되어 백업이 운영 워크로드를 방해할 수 있는 범위를 제한합니다. 이 매개 변수는 파일별로 백업 작업에 사용되는 대기 시간(밀리초 단위)을 지정합니다. 전체 효과는 영향을 받는 파일의 크기에 따라 부분적으로 달라집니다. 백업 성능을 MB/초 단위로 측정하면 백업 지연의 효과를 비교할 수 있습니다.

  • 정규 애플리케이션 로드와 동시에 백업을 실행하면 일반 로드 처리량에 부정적인 영향을 줍니다.
  • 그 영향은 경미하거나(약 5%) 매우 중요할 수 있으며, 처리량이 75%나 감소했으며, 이는 무엇보다도 애플리케이션에 따라 달라질 수 있습니다.
  • 백업은 CPU에서 부하가 많지 않으므로 CPU를 많이 사용하는 운영 워크로드는 입출력이 많은 작업보다 백업의 영향을 덜 받습니다.

chlimage_1-83

비교를 위해 'tar'를 사용하여 파일 시스템 백업을 사용하여 얻은 처리량을 비교하여 동일한 저장소 파일을 백업합니다. tar의 성능은 비교할 수 있지만 지연 시간이 0으로 설정된 백업보다 약간 높습니다. 작은 지연을 설정해도 백업 처리량이 크게 감소하며 기본 지연이 10ms로 설정되면 처리량이 크게 줄어듭니다. 전체 애플리케이션 사용량이 매우 낮거나 애플리케이션이 완전히 유휴 상태일 때 백업을 예약할 수 있는 경우 백업을 보다 신속하게 진행하기 위해 기본값 아래의 지연을 줄이는 것이 좋습니다.

지속적인 백업의 애플리케이션 처리량에 미치는 실제 영향은 애플리케이션 및 인프라 세부 사항에 따라 다릅니다. 지연 값 선택은 애플리케이션에 대한 경험적 분석을 통해 이루어져야 하지만 가능한 한 작게 선택하여 백업을 가능한 한 빨리 완료할 수 있어야 합니다. 지연 값 선택과 애플리케이션 처리량에 미치는 영향 간에는 상관관계가 약하기 때문에 지연을 선택하는 것이 전체 백업 시간을 단축하여 백업의 전반적인 영향을 최소화해야 합니다. 완료하는 데 8시간이 걸리지만 처리량이 -20%까지 영향을 받는 백업은 완료하는 데 2시간이 걸리지만 처리량이 -30%까지 영향을 미치는 백업 속도보다 전체적으로 큰 영향을 미칠 수 있습니다.

참조

이 페이지에서는

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free