자산 성능 조정

이 문서는 자산 성능 최적화에 도움이 되는 공통적인 자산 조정 구성 및 솔루션에 대해 설명합니다.

자산 성능 최적화

• Adobe는 많은 조직에서 업로드에 부정적인 영향을 주고 파일을 손상시키는 HTTP 트래픽을 차단하는 방화벽을 가지고 있기 때문에 HTTPS를 사용하는 것이 좋습니다.

• 대용량 파일 업로드의 경우 무선 대신 유선 연결을 사용합니다.

• 바이너리 파일에서는 tika 인덱스를 통해 전체 텍스트 검색을 사용하지 않습니다. 

• 아래 예에서는 최적의 JVM 매개 변수를 설정하고 Java 8을 사용합니다.

XX:+UseConcMarkSweepGC  = Enable Concurrent Mark Sweep (CMS) Collector-Doak.queryLimitInMemory=500000 -Doak.queryLimitReads=100000 -Dupdate.limit=250000 -Doak.fastQuerySize=true

• 슬링 작업 대기열 조정: 대규모 자산의 대량 업로드는 리소스가 많이 사용될 수 있습니다. 기본적으로 작업 대기열당 동시 스레드 수는 CPU 코어 수와 같으므로 전체 성능에 영향을 줄 수 있으며 Java 힙 사용량이 많아질 수 있습니다. 코어의 50%를 초과하지 않는 것이 좋습니다. 이 값을 변경하려면 http://:/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration으로 이동하여 queue.maxparallel을 AEM 인스턴스를 호스팅하는 서버 CPU 코어의 50%를 나타내는 값으로 설정합니다(예: CPU 코어가 8개인 경우 4로 설정). 

• CQBufferedImageCache의 캐시 크기 조정: 최대 힙(-Xmx param)이 5GB이고, Oak BlobCache가 1GB로 설정되어 있고, Document cache가 2GB로 설정된 시스템을 고려해 보겠습니다. 이 경우 버퍼링된 캐시는 최대 1.25GB를 차지하고, 예기치 않은 스파이크용으로 0.75GB 메모리만 남아 있습니다. 결국 JVM은 OutOfMemoryErrors로 실패합니다. 이 문제를 해결하려면 버퍼링된 이미지 캐시에 대해 구성된 최대 크기를 줄입니다. Adobe Experience Manager에 많은 양의 자산을 업로드할 때 OSGi Web Console.1을 통해 버퍼링된 캐시 크기를 구성하여 조정합니다. http://host:port/system/console/configMgr/com.day.cq.dam.core.impl.cache.CQBufferedImageCache2로 이동합니다. cq.dam.image.cache.max.memory 속성을 바이트로 설정합니다. 예를 들어, 1073741824는 1GB(1024*1024*1024 = 1GB)입니다. 참고: AEM 6.1 SP1부터는 이 속성 구성에 sling:osgiConfig 노드를 사용하는 경우 데이터 유형을 Long으로 설정해야 합니다. 이에 대한 자세한 내용은 이 문서를 참조하십시오.

• 사용 가능한 힙의 비율에 대해 FileDataStore를 사용할 때 cacheSizeInMB를 조정합니다. 적절한 값은 최대 힙의 2%입니다. 예를 들어, 8-gigabyteheap:maxCachedBinarySize=1048576cacheSizeInMB=164인 경우 최대 크기가 1MB인 파일만 캐시하도록 maxCachedBinarySize가 1MB(1048576)로 설정됩니다. 이 값을 더 작은 값으로 조정하는 것이 좋습니다. 많은 수의 바이너리를 처리할 때 성능을 최대화하기 위해 기본 노드 저장소 대신 외부 데이터 저장소를 사용하는 것이 좋습니다. 또한 다음 매개 변수를 조정할 것을 권장합니다.

• maxCachedBinarySize=10485760

• cacheSizeInMB=4096

주의: cacheSizeInMB 설정을 너무 높게 지정하면 java 프로세스의 메모리가 부족해질 수 있습니다. 예를 들어, 최대 힙 크기를 8GB(-Xmx8g)로 설정하고 AEM과 응용 프로그램이 4GB의 결합된 힙을 사용할 것으로 예상되는 경우 cacheSizeInMB를 164 대신 82로 설정하는 것이 좋습니다. 안전한 구성은 최대 힙의 2~10% 범위입니다. 그러나 메모리 사용률을 모니터링하는 동안 부하 테스트를 통해 이러한 설정의 변경을 확인하는 것이 좋습니다.

• DAM 업데이트 자산 작업 과정에는 Scene7 PTIFF 생성 및 InDesign Server 통합과 같은 작업에 대해 구성된 전체 단계 모음이 포함되어 있습니다. 그러나 대부분의 사용자는 이러한 단계 중 몇 가지가 필요하지 않을 수 있습니다. DAM 자산 업데이트 작업 과정 모델의 사용자 지정 복사본을 만들고 불필요한 단계를 제거하는 것이 좋습니다. 이 경우 DAM 자산 업데이트 실행 프로그램이 새 모델을 가리키도록 업데이트합니다.

• 임시 작업 과정: 높은 처리 부하를 최적화하기 위해 DAM 업데이트와 XMP 메타데이터 원본에 쓰기 작업 과정을 임시 작업 과정으로 전환하는 것이 좋습니다. 이름에서 알 수 있듯이 임시 작업 과정의 중간 작업 단계와 관련된 런타임 데이터는 실행될 때 JCR에서 유지되지 않습니다(물론 출력 렌디션은 유지됨). 이로 인해 작업 과정 처리 시간이 10% 단축되고 저장소 증가가 현저하게 줄어듭니다. 더 이상 CRUD 작업 과정을 제거하지 않아도 됩니다. 또한 압축할 TAR 파일 수가 줄어듭니다. 업무상 감사를 위해 지속적/보관 중인 작업 과정 런타임 데이터를 지정하는 경우 이 기능을 사용하지 마십시오.

• 선택적 렌더링 생성: 자산 처리 작업 과정에 조건을 추가하여 필요한 렌디션만 생성하므로 선택 자산에 대해서만 비용이 더 많이 드는 렌디션이 생성됩니다./작업 과정/ DAM 자산 업데이트 >> 축소판 처리 단계.

• 인스턴스 간에 공유된 데이터 저장소: S3 또는 공유 파일 데이터 저장소를 구현하면 대규모 구현 시 디스크 공간을 절약하고 네트워크 처리량을 늘릴 수 있습니다. 하지만 그러한 배포를 유지하는 데 다른 추가적인 작업이 있을 수 있습니다. 그렇지만 이렇게 하는 것이 성능 향상을 위한 적절한 절충안일 수 있습니다.

• 유지 관리: 일반적으로 매주 정리 작업 과정을 실행해야 합니다. 그러나 대규모 자산 처리 중일 때와 같이 리소스를 많이 사용하는 시나리오에서는 더 자주 실행할 수 있습니다.