이 페이지에서는 AEM 배포 성능을 최적화하는 방법에 대한 일반 지침을 제공합니다. AEM을 처음 사용하는 경우 성능 지침을 읽기 전에 다음 페이지를 검토하십시오.
아래 그림은 AEM에 사용할 수 있는 배포 옵션(모든 옵션을 보려면 스크롤)입니다.
AEM 제품 |
토폴로지 |
운영 체제 |
응용 프로그램 서버 |
JRE |
보안 |
마이크로 커널 |
데이터 저장소 |
색인 생성 |
웹 서버 |
브라우저 |
Marketing Cloud |
Sites |
비-HA |
Windows |
CQSE |
Oracle |
LDAP |
Tar |
세그먼트 |
속성 |
Apache |
Edge |
대상 |
에셋 |
Publish-HA |
Solaris |
WebLogic |
IBM |
SAML |
MongoDB |
파일 |
Lucene |
IIS |
IE |
분석 |
커뮤니티 |
Author-CS |
빨간색 모자 |
WebSphere |
HP |
Oauth |
RDB/Oracle |
S3/Azure |
Solr |
iPlanet |
FireFox |
캠페인 |
Forms |
작성자 오프로드 |
HP-UX |
Tomcat |
|
|
RDB/DB2 |
MongoDB |
|
|
Chrome |
Social |
모바일 |
Author-Cluster |
IBM AIX |
JBoss |
|
|
RDB/MySQL |
RDBMS |
|
|
Safari |
대상자 |
다중 사이트 |
ASRP |
SUSE |
|
|
|
RDB/SQLServer |
|
|
|
|
에셋 |
상거래 |
MSRP |
Apple OS |
|
|
|
|
|
|
|
|
활성화 |
Dynamic Media |
JSRP |
|
|
|
|
|
|
|
|
|
모바일 |
Brand Portal |
J2E |
|
|
|
|
|
|
|
|
|
|
AoD |
|
|
|
|
|
|
|
|
|
|
|
LiveFyre |
|
|
|
|
|
|
|
|
|
|
|
스크린 |
|
|
|
|
|
|
|
|
|
|
|
문서 보안 |
|
|
|
|
|
|
|
|
|
|
|
프로세스 Mgt |
|
|
|
|
|
|
|
|
|
|
|
데스크탑 앱 |
|
|
|
|
|
|
|
|
|
|
|
성능 지침은 주로 AEM Sites에 적용됩니다.
다음과 같은 경우에는 성능 지침을 사용해야 합니다.
이 장에서는 AEM 아키텍처와 가장 중요한 구성 요소에 대한 일반적인 개요를 제공합니다. 또한 개발 지침을 제공하며 TarMK 및 MongoMK 벤치마크 테스트에 사용되는 테스트 시나리오에 대해 설명합니다.
AEM 플랫폼은 다음 구성 요소로 구성됩니다.
AEM 플랫폼에 대한 자세한 내용은 AEM 소개.
AEM 배포에는 세 가지 중요한 구성 요소가 있습니다. 다음 작성자 인스턴스 컨텐츠 작성자, 편집자 및 승인자가 컨텐츠를 만들고 검토하는 데 사용하는 컨텐츠입니다. 컨텐츠가 승인되면 이름이 게시 인스턴스 최종 사용자가 액세스할 수 있는 위치. 세 번째 빌딩 블록은 Dispatcher 캐싱 및 URL 필터링을 처리하는 모듈이며 웹 서버에 설치됩니다. AEM 아키텍처에 대한 자세한 내용은 일반적인 배포 시나리오.
Micro Kernels는 AEM에서 지속성 관리자 역할을 합니다. AEM에 사용되는 세 가지 유형의 마이크로 커널이 있습니다. TarMK, MongoDB 및 관계형 데이터베이스(제한된 지원 아래). 고려하고 있는 인스턴스의 목적 및 배포 유형에 따라 본인의 요구에 맞는 것을 하나 선택합니다. 마이크로 커널에 대한 자세한 내용은 권장 배포 페이지.
AEM에서 이진 데이터는 컨텐츠 노드와 독립적으로 저장할 수 있습니다. 이진 데이터가 저장되는 위치를 데이터 저장소인 반면 컨텐츠 노드 및 속성의 위치는 노드 저장소.
Adobe은 TarMK를 AEM 작성자 및 게시 인스턴스 둘 다에 대해 고객이 사용하는 기본 지속성 기술로 권장합니다.
관계형 데이터베이스 마이크로 커널은 제한된 지원 하에 있습니다. 연락처 고객 지원 Adobe 이러한 유형의 마이크로 커널을 사용하기 전에
많은 바이너리를 처리할 때 성능을 최대화하기 위해 기본 노드 저장소 대신 외부 데이터 저장소를 사용하는 것이 좋습니다. 예를 들어 프로젝트에 많은 미디어 자산이 필요한 경우 파일 또는 Azure/S3 데이터 저장소 아래에 저장하면 MongoDB에 직접 저장하는 것보다 더 빠르게 미디어 자산에 액세스할 수 있습니다.
사용 가능한 구성 옵션에 대한 자세한 내용은 노드 및 데이터 저장소 구성.
Adobe은 Adobe Managed Services를 사용하여 AEM을 Azure에 배포하거나 Amazon Web Services(AWS)에 배포하는 옵션을 선택할 것을 권장합니다. 이 경우 고객은 이러한 클라우드 컴퓨팅 환경에서 AEM을 배포하고 운영하는 경험과 기술을 갖춘 팀으로부터 혜택을 받을 수 있습니다. 다음을 확인하십시오 Adobe Managed Services에 대한 추가 설명서.
Adobe Managed Services의 외부에서 Azure 또는 AWS에 AEM을 배포하는 방법에 대한 권장 사항을 제공하려면 클라우드 제공업체 또는 선택한 클라우드 환경에서 AEM을 배포하도록 지원하는 Adobe 파트너 중 하나와 직접 작업하는 것이 좋습니다. 선택한 클라우드 제공업체 또는 파트너는 특정 성능, 로드, 확장성 및 보안 요구 사항을 충족하기 위해 지원할 아키텍처의 크기 조정 사양, 디자인 및 구현을 책임집니다.
자세한 내용은 기술 요구 사항 페이지.
이 섹션에 나열된 항목은 AEM과 함께 사용되는 사용자 지정 인덱스 공급자입니다. 색인에 대한 자세한 내용은 Oak 쿼리 및 색인 지정.
대부분의 배포의 경우 Lucene 인덱스를 사용하는 것이 좋습니다. 특수 및 복잡한 배포에 Solr만 사용해야 합니다.
타겟 AEM용으로 개발해야 합니다 성능 및 확장성. 다음은 따라야 할 많은 모범 사례입니다.
DO
금지
가능하면 JCR API를 직접 사용하지 마십시오
/libs를 변경하지 말고 오버레이를 사용하십시오
가능하면 쿼리를 사용하지 마십시오
Sling 바인딩을 사용하여 Java 코드에서 OSGi 서비스를 가져오지 않고 를 사용합니다.
AEM 개발에 대한 자세한 내용은 개발 - 기본 사항. 추가 우수 사례에 대해서는 개발 우수 사례.
이 페이지에 표시되는 모든 벤치마크 테스트는 실험 설정에서 수행되었습니다.
아래에 자세히 설명된 테스트 시나리오는 TarMK, MongoMk 및 TarMK 및 MongoMk 장의 벤치마크 섹션에 사용됩니다. 특정 벤치마크 테스트에 사용된 시나리오를 보려면 기술 사양 테이블.
단일 제품 시나리오
AEM Assets:
혼합 제품 시나리오
AEM Sites + 자산:
세로 사용 사례 시나리오
미디어:
이 장에서는 최소 아키텍처 요구 사항 및 설정 구성을 지정하는 TarMK에 대한 일반 성능 지침을 제공합니다. 벤치마크 테스트도 더 명확히 하기 위해 제공됩니다.
Adobe은 TarMK를 AEM 작성자 및 게시 인스턴스 모두에 대해 모든 배포 시나리오에서 고객이 사용하는 기본 지속성 기술로 권장합니다.
TarMK에 대한 자세한 내용은 배포 시나리오 및 Tar 저장소.
아래에 나와 있는 최소 아키텍처 지침은 프로덕션 환경과 높은 트래픽 사이트에 대한 것입니다. 이것들은 not a 최소 사양 AEM을 실행하는 데 필요합니다.
TarMK를 사용할 때 성능을 제대로 설정하려면 다음 아키텍처에서 시작해야 합니다.
아래 그림은 AEM Sites 및 AEM Assets에 대한 아키텍처 지침입니다.
바이너리 없는 복제 기능 사용 설정 파일 데이터 저장소가 공유되는 경우
AEM Sites에 대한 Tar 아키텍처 지침
AEM Assets에 대한 Tar 아키텍처 지침
성능을 향상시키기 위해 아래에 표시된 설정 지침을 따라야 합니다. 설정을 변경하는 방법에 대한 지침은 이 페이지 보기.
설정 | 매개변수 | 값 | 설명 |
Sling 작업 큐 | queue.maxparallel |
값을 CPU 코어 수의 절반으로 설정합니다. | 기본적으로 작업 큐당 동시 스레드 수는 CPU 코어 수와 같습니다. |
Granite Transient 워크플로 큐 | Max Parallel |
값을 CPU 코어 수의 절반으로 설정합니다. | |
JVM 매개 변수 |
|
500000 100000 250000 True |
AEM 시작 스크립트에 이러한 JVM 매개 변수를 추가하여 광범위한 쿼리가 시스템을 오버로드하지 못하도록 합니다. |
Lucene 인덱스 구성 |
|
활성화됨 활성화됨 활성화됨 |
사용 가능한 매개 변수에 대한 자세한 내용은 이 페이지. |
데이터 저장소 = S3 데이터 저장소 |
|
1048576(1MB) 이하 최대 heap 크기의 2-10% |
참조 - 데이터 저장소 구성. |
DAM 자산 업데이트 워크플로우 | Transient Workflow |
선택함 | 이 워크플로우는 자산 업데이트를 관리합니다. |
DAM 메타데이터 원본에 쓰기 | Transient Workflow |
선택함 | 이 워크플로우는 원래 바이너리에 대한 XMP 다시 쓰기를 관리하고 JCR에서 마지막으로 수정한 날짜를 설정합니다. |
벤치마크 테스트는 다음 사양에 따라 수행되었습니다.
작성자 노드 | |
---|---|
서버 | 베어 메탈 하드웨어(HP) |
운영 체제 | RedHat Linux |
CPU/코어 | Intel® Xeon® CPU E5-2407 @2.40GHz, 8개 코어 |
RAM | 32GB |
디스크 | 자석 |
Java | Oracle JRE 버전 8 |
JVM Heap | 16GB |
제품 | AEM 6.2 |
노데스토르 | TarMK |
데이터 저장소 | 파일 DS |
시나리오 | 단일 제품: 자산 / 30개의 동시 스레드 |
아래 표시된 숫자는 기준 요소로 1로 표준화되었으며 실제 처리량 숫자는 아닙니다.
TarMK보다 MongoMK 지속성 백엔드를 선택하는 주된 이유는 인스턴스를 가로로 크기 조절하기 위한 것입니다. 즉, 두 개 이상의 활성 작성자 인스턴스가 항상 실행되고 MongoDB를 지속성 스토리지 시스템으로 사용합니다. 일반적으로 두 개 이상의 작성 인스턴스를 실행해야 하는 이유는 모든 동시 작성 활동을 지원하는 단일 서버의 CPU 및 메모리 용량이 더 이상 지속되지 않기 때문입니다.
TarMK에 대한 자세한 내용은 배포 시나리오 및 Mongo 저장소.
MongoMK를 사용할 때 좋은 성능을 설정하려면 다음 아키텍처에서 시작해야 합니다.
운영 환경에서 MongoDB는 항상 운영 및 2개의 보조 복제본이 있는 복제 세트로 사용됩니다. 읽기 및 쓰기 작업은 운영 사이트로 이동하고 읽기는 보조 스토리지로 이동할 수 있습니다. 스토리지를 사용할 수 없는 경우 보조 노드 중 하나를 중재자로 교체할 수 있지만 MongoDB 복제본 세트는 항상 인스턴스 수가 홀수로 구성되어야 합니다.
바이너리 없는 복제 기능 사용 설정 파일 데이터 저장소가 공유되는 경우
성능을 향상시키기 위해 아래에 표시된 설정 지침을 따라야 합니다. 설정을 변경하는 방법에 대한 지침은 이 페이지 보기.
설정 | 매개변수 | 값(기본값) | 설명 |
Sling 작업 큐 | queue.maxparallel |
값을 CPU 코어 수의 절반으로 설정합니다. | 기본적으로 작업 큐당 동시 스레드 수는 CPU 코어 수와 같습니다. |
Granite Transient 워크플로 큐 | Max Parallel |
값을 CPU 코어 수의 절반으로 설정합니다. | |
JVM 매개 변수 |
|
500000 100000 250000 True 60000 |
AEM 시작 스크립트에 이러한 JVM 매개 변수를 추가하여 광범위한 쿼리가 시스템을 오버로드하지 못하도록 합니다. |
Lucene 인덱스 구성 |
|
활성화됨 활성화됨 활성화됨 |
사용 가능한 매개 변수에 대한 자세한 내용은 이 페이지. |
데이터 저장소 = S3 데이터 저장소 |
|
1048576(1MB) 이하 최대 heap 크기의 2-10% |
참조 - 데이터 저장소 구성. |
DocumentNodeStoreService |
|
2048년 35 (25) 20 (10) 30 (5) 10 (3) 4. 4 ./cache,size=2048,binary=0,-compact,-compress |
캐시의 기본 크기가 256MB로 설정되어 있습니다. 캐시 무효화를 수행하는 데 걸리는 시간에 영향을 줍니다. |
oak-observation |
|
min 및 max = 20 50000 |
벤치마크 테스트는 다음 사양에 따라 수행되었습니다.
작성자 노드 | MongoDB 노드 | |
---|---|---|
서버 | 베어 메탈 하드웨어(HP) | 베어 메탈 하드웨어(HP) |
운영 체제 | RedHat Linux | RedHat Linux |
CPU/코어 | Intel® Xeon® CPU E5-2407 @2.40GHz, 8개 코어 | Intel® Xeon® CPU E5-2407 @2.40GHz, 8개 코어 |
RAM | 32GB | 32GB |
디스크 | 마그네틱 - 1k IOPS 이상 | 마그네틱 - 1k IOPS 이상 |
Java | Oracle JRE 버전 8 | 해당 없음 |
JVM Heap | 16GB | 해당 없음 |
제품 | AEM 6.2 | MongoDB 3.2 WiredTiger |
노데스토르 | MongoMK | 해당 없음 |
데이터 저장소 | 파일 DS | 해당 없음 |
시나리오 | 단일 제품: 자산 / 30개의 동시 스레드 | 단일 제품: 자산 / 30개의 동시 스레드 |
아래 표시된 숫자는 기준 요소로 1로 표준화되었으며 실제 처리량 숫자는 아닙니다.
두 가지 중 하나를 선택할 때 고려해야 하는 기본 규칙은 TarMK가 성능용으로 설계된 반면 MongoMK는 확장성을 위해 사용됩니다. Adobe은 TarMK를 AEM 작성자 및 게시 인스턴스 모두에 대해 모든 배포 시나리오에서 고객이 사용하는 기본 지속성 기술로 권장합니다.
TarMK보다 MongoMK 지속성 백엔드를 선택하는 주된 이유는 인스턴스를 가로로 크기 조절하기 위한 것입니다. 즉, 두 개 이상의 활성 작성자 인스턴스가 항상 실행되고 MongoDB를 지속성 스토리지 시스템으로 사용합니다. 일반적으로 두 개 이상의 작성 인스턴스를 실행해야 하는 이유는 모든 동시 작성 활동을 지원하는 단일 서버의 CPU 및 메모리 용량이 더 이상 지속되지 않기 때문입니다.
TarMK와 MongoMK에 대한 자세한 내용은 권장 배포.
TarMK의 이점
MongoMK 선택 기준
아래 표시된 숫자가 기준 요소로 1로 표준화되었으며 실제 처리량 숫자는 아닙니다.
작성자 OAK 노드 | MongoDB 노드 | ||
서버 | 베어 메탈 하드웨어(HP) | 베어 메탈 하드웨어(HP) | |
운영 체제 | RedHat Linux | RedHat Linux | |
CPU/코어 | Intel(R) Xeon(R) CPU E5-2407 @2.40GHz, 8개 코어 | Intel(R) Xeon(R) CPU E5-2407 @2.40GHz, 8개 코어 | |
RAM | 32GB | 32GB | |
디스크 | 마그네틱 - 1k IOPS 이상 | 마그네틱 - 1k IOPS 이상 | |
Java | Oracle JRE 버전 8 | 해당 없음 | |
JVM Heap16GB | 16GB | 해당 없음 | |
제품 | AEM 6.2 | MongoDB 3.2 WiredTiger | |
노데스토르 | TarMK 또는 MongoMK | 해당 없음 | |
데이터 저장소 | 파일 DS | 해당 없음 | |
시나리오 |
|
MongoDB와 TarMK 시스템 한 대와 동일한 수의 작성자를 활성화하려면 두 개의 AEM 노드가 있는 클러스터가 필요합니다. 네 개의 노드 MongoDB 클러스터는 Author의 1.8배를 TarMK 인스턴스보다 처리할 수 있습니다. 8개의 노드 MongoDB 클러스터는 Authors 수의 2.3배를 TarMK 인스턴스보다 처리할 수 있습니다.
작성자 TarMK 노드 | 작성자 MongoMK 노드 | MongoDB 노드 | |
서버 | AWS c3.8xlarge | AWS c3.8xlarge | AWS c3.8xlarge |
운영 체제 | RedHat Linux | RedHat Linux | RedHat Linux |
CPU/코어 | 32 | 32 | 32 |
RAM | 60GB | 60GB | 60GB |
디스크 | SSD - 10k IOPS | SSD - 10k IOPS | SSD - 10k IOPS |
Java | Oracle JRE 버전 8 | Oracle JRE 버전 8 |
해당 없음 |
JVM Heap16GB | 30GB | 30GB | 해당 없음 |
제품 | AEM 6.2 | AEM 6.2 | MongoDB 3.2 WiredTiger |
노데스토르 | TarMK | MongoMK | 해당 없음 |
데이터 저장소 | 파일 DS | 파일 DS |
해당 없음 |
시나리오 |
|
이 페이지에 제시된 지침은 다음과 같이 요약할 수 있습니다.
파일 데이터 저장소가 있는 TarMK 대부분의 고객을 위한 권장 아키텍처입니다.
파일 데이터 저장소가 있는 MongoMK 작성 계층의 수평 확장성을 위한 권장 아키텍처입니다.
노데스토르 NAS(Network Attached Storage)가 아니라 로컬 디스크에 저장해야 합니다.
사용 시 Amazon S3:
기본 색인과 함께 사용자 지정 색인을 만들어야 합니다 가장 일반적인 검색 기준
워크플로우를 사용자 지정하여 성능을 크게 향상시킬 수 있습니다예를 들어 "자산 업데이트" 워크플로우에서 비디오 단계를 제거하여 사용하지 않는 수신기를 비활성화하는 등의 작업을 수행합니다.
자세한 내용은 권장 배포 페이지.