성능 최적화 performance-optimization

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

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

작성 환경 author-environment

이 환경은 컨텐츠 입력 및 업데이트 작성자가 사용합니다. 이 콘텐츠는 콘텐츠 페이지와 해당 페이지의 개별 요소를 업데이트할 때 각각 높은 수의 성능 집약적인 요청을 생성하는 소수의 사용자를 대상으로 해야 합니다.

게시 환경 publish-environment

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

성능 최적화 방법론 performance-optimization-methodology

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

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

최적화 계획 planning-for-optimization

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

가능한 경우, 전체 발표 후 추가적인 압력 없이 실시간 경험을 수집하고 추가 최적화를 수행하기 위해 제한된 대상에 프로젝트를 먼저 소프트 런칭해야 합니다.

일단 "라이브"가 되면 성능 최적화는 종료되지 않습니다. 시스템에 "실제" 로드가 표시되는 시점입니다. 발사 후에 추가적인 조정을 계획하는 것이 중요합니다.

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

현실 시뮬레이션 simulate-reality

웹 사이트를 통해 라이브로 전환하고 실행 후 성능 문제가 발생하는 경우를 알 수 있는 경우 다음과 같은 한 가지 이유가 있습니다. 부하 테스트와 성능 테스트만으로 실제 상황을 거의 시뮬레이션하지 못했습니다.

현실을 시뮬레이션하는 것은 어렵고 "실제"에 투자하기 위해 합리적으로 얼마나 많은 노력을 기울이느냐에 따라 다릅니다. "실수"는 "실제 코드"와 "실제 트래픽"뿐만 아니라 특히 컨텐츠 크기 및 구조에 대한 "실제 컨텐츠"를 의미합니다. 템플릿의 크기 및 구조에 따라 템플릿이 완전히 다를 수 있습니다.

확고한 목표 설정 establish-solid-goals

성능 목표를 제대로 수립해야 한다는 중요성은 과소평가되지 않는다. 종종, 사람들이 특정 성과 목표에 집중하게 되면, 그들이 야생적인 가정을 기반으로 한다고 할지라도, 그 후에 이러한 목표를 변경하는 것은 매우 어렵습니다.

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

연관성 유지 stay-relevant

한 번에 하나의 병목 현상을 최적화하는 것이 중요합니다. 하나의 최적화의 영향을 확인하지 않고 작업을 동시에 수행하려고 하면 실제로 도움을 준 최적화 측정을 제대로 추적하지 못합니다.

애자일 반복 주기 agile-iteration-cycles

성능 조정은 목표에 도달할 때까지 측정, 분석, 최적화 및 검증을 포함하는 반복 프로세스입니다. 이러한 측면을 적절히 고려하려면 각 반복 후에 가중치가 높은 테스트 프로세스가 아니라 최적화 단계에서 애자일 유효성 검사 프로세스를 구현합니다.

즉, 최적화를 구현하는 개발자가 최적화가 이미 목표에 도달했는지 신속하게 알 수 있어야 합니다. 목표에 도달하면 최적화가 완료되기 때문에 중요한 정보입니다.

기본 성능 지침 basic-performance-guidelines

일반적으로, 연결 해제된 html 요청을 100ms 미만으로 유지합니다. 특히 다음 사항이 지침이 될 수 있습니다.

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

성능 문제에 자주 기여하는 몇 가지 문제가 있습니다. 이러한 중심은 다음과 같습니다.

JVM 및 OS 레벨 튜닝은 일반적으로 성능이 크게 향상되지 않으므로 최적화 주기 마지막 시점에 수행해야 합니다.

컨텐츠 리포지토리의 구성 방식 역시 성능에 영향을 줄 수 있습니다. 최상의 성능을 위해 컨텐츠 저장소의 개별 노드에 첨부된 하위 노드의 수는 1,000개를 초과할 수 없습니다(일반 규칙).

일반적인 성능 최적화 운동 중 가장 친한 친구는 다음과 같습니다.

디지털 자산을 로드하고 편집할 때의 성능 performance-when-loading-and-editing-digital-assets

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

성능에 영향을 주는 두 가지 사항은 다음과 같습니다.

성능을 향상시키기 위해 다음을 고려할 수 있습니다.

성능 모니터링 performance-monitoring

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

성능 모니터링 수행 방법에 대한 자세한 내용은 성능 모니터링.

성능 문제를 일으키는 문제는 그 효과를 쉽게 볼 수 있는 경우에도 추적하기가 어려운 경우가 많습니다.

기본 시작점은 정상적으로 작동하는 시스템에 대한 유용한 정보입니다. 환경이 제대로 작동할 때 "보기" 및 "동작"하는 방식을 모른다면, 성능이 저하될 때 문제를 찾기가 어려울 수 있습니다. 즉, 시스템이 원활하게 실행될 때 시스템을 조사하는 데 시간이 좀 걸리고 성능 정보 수집이 지속적인 작업인지 확인해야 합니다. 이렇게 하면 성능이 저하될 경우 비교 기준이 제공됩니다.

다음 다이어그램은 AEM 컨텐츠에 대한 요청이 수행할 수 있는 경로를 보여 주기 때문에 성능에 영향을 줄 수 있는 다양한 요소의 수를 보여줍니다.

성능도 볼륨과 용량 간의 균형입니다.

볼륨 시스템에서 처리 및 전달되는 출력의 양입니다.

용량 볼륨을 전달하는 시스템의 기능입니다.

이러한 내용은 웹 체인 전체에서 다양한 위치에 표시될 수 있습니다.

성능에 영향을 주는 요소는 다음과 같습니다.

성능에 대한 기본 규칙 basic-rules-regarding-performance

성능 최적화 시 특정 규칙을 염두에 두어야 합니다.

성능 구성 configuring-for-performance

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

검색 색인 지정 search-indexing

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

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

동시 워크플로우 처리 concurrent-workflow-processing

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

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

워크플로우 엔진은 작업 항목 처리를 처리하고 예약하기 위해 Apache Sling 작업 큐를 사용합니다. 워크플로우 작업 처리를 위한 Apache Sling Job Queue Configuration 서비스 팩토리에서 기본적으로 다음 작업 큐 서비스를 만들었습니다.

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

참고: 특정 워크플로우 모델에 대한 작업 큐를 만들지 않은 경우 이러한 작업 큐를 구성하는 것은 모든 워크플로우에 영향을 줍니다(참조 특정 워크플로우 모델에 대한 큐 구성 아래에 표시됩니다.

저장소의 구성 configuration-in-the-repo

서비스를 구성하는 경우 sling:OsgiConfig 노드 사용를 찾으려면 기존 서비스의 PID를 찾아야 합니다. 예를 들면 다음과 같습니다. org.apache.sling.event.jobs.QueueConfiguration.370aad73-d01b-4a0b-abe4-20198d85f705. 웹 콘솔을 사용하여 PID를 검색할 수 있습니다.

이름이 지정된 속성을 구성해야 합니다 queue.maxparallel.

웹 콘솔에서 구성 configuration-in-the-web-console

이러한 서비스를 구성하려면 웹 콘솔 사용를 찾으려면 Apache Sling Job Queue Configuration 서비스 팩토리 아래에서 기존 구성 항목을 찾습니다.

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

특정 워크플로우에 대한 큐 구성 configure-the-queue-for-a-specific-workflow

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

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

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

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

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

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

AEM DAM 자산 동기화 서비스 cq-dam-asset-synchronization-service

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

이 작업은 OSGi 서비스 구성 CQ DAM 자산 동기화 서비스 를 동기화 기간 ( scheduler.period) ~ (최소) 1년(초 단위로 정의됨).

여러 DAM 인스턴스 multiple-dam-instances

예를 들어 다음과 같은 경우 여러 DAM 인스턴스를 배포하면 성능이 향상됩니다.

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

품질 보증 우수 사례 best-practices-for-quality-assurance

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

이 섹션에서는 사용자의 성능 테스트를 위해 특별히 테스트 개념을 정의하는 것과 관련된 문제에 대해 표준화된 개요를 제공하는 것을 목표로 합니다 게시 환경. QA 엔지니어, 프로젝트 관리자 및 시스템 관리자에게 주로 관심이 있습니다.

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

제어는 필수 사항이지만 테스트에만 국한되지 않는 모든 프로세스를 포괄하는 추가 프로세스입니다.

지식 확인 verification-of-knowledge

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

테스트 아키텍처 test-architecture

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

디스패처 및 로드 밸런서와 함께 계획된 프로덕션 게시 환경을 재생해야 합니다.

응용 프로그램 맵 application-map

전체 애플리케이션의 맵을 만들 수 있으므로 명확한 개요를 알 수 있습니다(작성 환경의 테스트에서 이 맵을 얻을 수 있음).

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

범위 정의 scope-definition

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

게시에서 성능 테스트 범위에 집중하려면 다음을 정의하는 것이 좋습니다.

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

주요 사용 사례를 선택한 후 KPI(주요 성능 지표)와 이를 측정하는 데 사용되는 도구를 각 사례에 대해 정의할 수 있습니다. 일반적인 KPI의 예는 다음과 같습니다.

테스트 방법론 test-methodologies

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

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

구성 요소 중단점 component-breakpoints

트랜잭션 transactions

성능 목표 정의 defining-the-performance-goals

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

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

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

단일 구성 요소 테스트 single-component-tests

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

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

결합된 구성 요소 테스트 combined-component-tests

구성 요소를 조합하여 테스트하면 애플리케이션 동작이 더 잘 반영됩니다. 다시 평균과 최고 상태를 테스트해야 합니다.

라이브 테스트 진행 going-live-tests

웹 사이트를 방문한 후 처음 며칠간은 관심 수준이 높아질 것입니다. 이것은 테스트한 최대값보다 더 클 수 있습니다. 시스템이 이 상황을 처리할 수 있도록 Go Live 시나리오를 테스트하는 것이 좋습니다.

오류 시나리오 테스트 error-scenario-tests

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

이 시험들을 고안할 때, 모든 시나리오가 규칙적으로 일어나는 것은 아니라는 것을 기억해야만 한다. 그러나 이들이 전체 시스템에 미치는 영향은 중요하다.

지구력 테스트 endurance-tests

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

최적화 optimization

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

다음과 같은 최적화를 테스트해야 합니다.

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

최적화 후 다시 테스트하여 영향을 확인해야 합니다.

보고 reporting

진행 중인 보고는 모든 사람이 상태를 계속 알 수 있도록 해야 합니다. 앞서 색상 코딩에서 언급했듯이 아키텍처 맵은 여기에 사용할 수 있습니다.

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

Dispatcher 사용 시 성능 최적화 optimizing-performance-when-using-the-dispatcher

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

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

디스패처 캐시 비율 계산 calculating-the-dispatcher-cache-ratio

캐시 비율 수식은 시스템으로 들어오는 총 요청 수 중 캐시에서 처리한 요청의 비율을 예측합니다. 캐시 비율을 계산하려면 다음 항목이 필요합니다.

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

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

한 대 하나의 게시자/디스패처 쌍이 없는 경우 정확한 측정을 위해 모든 디스패처 및 게시자의 요청을 함께 추가해야 합니다. 참조 - 권장 배포.

일관된 페이지 인코딩 사용 using-consistent-page-encoding

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

        <META http-equiv="Content-Type" content="text/html; charset=EUC-JP">

URL 매개 변수 방지 avoid-url-parameters

가능하면 캐시하려는 페이지의 URL 매개 변수를 사용하지 마십시오. 예를 들어 사진 갤러리가 있는 경우 다음 URL은 캐시되지 않습니다(Dispatcher가 적절하게 구성되지 않은 경우).

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

단, 다음과 같이 이러한 매개 변수를 페이지 URL에 넣을 수 있습니다.

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

URL로 사용자 지정 customize-by-url

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

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

URL에 글꼴 크기를 선택기로 포함하면 이 문제를 피할 수 있습니다.

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

제목으로 사용된 이미지 파일 무효화 invalidating-image-files-used-as-titles

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

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

탐색에 사용된 이미지 파일 무효화 invalidating-image-files-used-for-navigation

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

콘텐츠 업데이트가 페이지와 함께 이러한 사진을 삭제하도록 하려면 페이지와 동일한 이름 지정 핸들을 사용하여 이러한 사진을 만드는 것이 중요합니다.

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

개인화 personalization

개인화를 필요한 위치로 제한하는 것이 좋습니다. 이유는 다음과 같습니다.

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

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

고정 연결 sticky-connections

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

MIME 유형 mime-types

브라우저가 파일 유형을 결정할 수 있는 두 가지 방법이 있습니다.

대부분의 파일에서 MIME 유형은 파일 확장명에 암시되어 있습니다. 즉,

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

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

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

백업 성능 backup-performance

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

참조 환경 reference-environment

물리적 시스템 physical-system

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

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

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

데이터 볼륨 data-volumes

다음 표는 백업 벤치마크에서 사용되는 데이터 볼륨의 크기를 보여 줍니다. 초기 기준 컨텐츠를 먼저 설치한 다음 알려진 추가 데이터 양이 추가되어 백업된 컨텐츠의 크기를 늘립니다. 특정 증분으로 백업이 작성되어 컨텐츠가 크게 증가하며 하루 단위로 생성될 수 있습니다. 컨텐츠(페이지, 이미지, 태그)의 배포는 실제 프로덕션 자산 구성을 기반으로 대략적으로 달라집니다. 페이지, 이미지 및 태그는 최대 800개의 하위 페이지로 제한됩니다. 각 페이지에는 제목, Flash, 텍스트/이미지, 비디오, 슬라이드쇼, 양식, 테이블, 클라우드 및 회전 메뉴 구성 요소가 포함됩니다. 이미지는 37kB에서 594kB에 이르는 400개의 고유 파일 풀에서 업로드됩니다.

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

벤치마크 시나리오 benchmark-scenarios

백업 벤치마크는 다음 두 가지 주요 시나리오를 다룹니다. 시스템이 상당한 응용 프로그램을 로드하고 시스템이 유휴 상태일 때 백업을 수행합니다. 일반적으로 AEM이 유휴 상태일 때 백업을 수행해야 하지만 시스템이 로드될 때 백업을 실행해야 하는 경우가 있습니다.

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

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

이 응용 프로그램을 로드하지 않은 성능과 성능 간의 차이로 인해 백업 성능에 대한 로드 영향을 예측할 수 있습니다. 백업 처리량이 애플리케이션 처리량에 미치는 영향을 찾기 위해서는 시간당 트랜잭션의 시나리오 처리량과 동시 백업이 진행 중인 백업 및 다른 "백업 지연" 설정으로 작동하는 백업 데이터를 비교해야 합니다.

결과 요약 summary-of-results

백업 시간 및 처리량 backup-time-and-throughput

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

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

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

이 차트에서는 증가분 및 전체 백업 모두 간단한 크기와 처리 속도로 측정할 수 있는 시간 패턴을 따르는 것을 보여줍니다. 유휴 인스턴스의 백업 시간은 매우 일관되며 벤치마크 환경의 전체 백업이나 증분 백업에 관계없이 평균 0.61MB/초입니다.

백업 지연 backup-delay

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

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

지속적인 백업의 애플리케이션 처리량이 미치는 실제 영향은 애플리케이션과 인프라 세부 정보에 따라 달라집니다. 애플리케이션의 경험적 분석을 통해 지연 값을 선택할 수 있지만 가능한 한 적은 수의 데이터를 선택하여 백업이 가능한 한 빨리 완료되도록 해야 합니다. 지연 값 선택과 애플리케이션 처리량에 미치는 영향 간에 상관성이 미약하므로 전체 백업 시간을 단축하여 전체 백업 시간의 영향을 최소화해야 합니다. 완료하는 데 8시간이 걸리지만 처리량이 -20%까지 영향을 받는 백업은 전체 영향을 2시간이 걸리지만 처리량이 -30%까지 영향을 미치는 백업보다 더 클 수 있습니다.

참조 references