캐싱 및 성능

구성 요소 및 GraphQL 응답 캐싱

AEM CIF 핵심 구성 요소에는 이미 개별 구성 요소에 대한 GraphQL 응답을 캐시하는 기능이 내장되어 있습니다. 이 기능을 사용하면 GraphQL 백엔드 호출 수를 크게 줄일 수 있습니다. 특히 탐색 구성 요소에 대한 범주 트리를 검색하거나 제품 검색 및 범주 페이지에 표시된 모든 사용 가능한 집계/패싯 값을 가져오는 등의 반복 쿼리에 효과적인 캐싱을 수행할 수 있습니다.

AEM CIF 핵심 구성 요소의 경우 캐싱이 구성 요소 기반으로 구성되므로 각 구성 요소에 대해 GraphQL 요청/응답이 캐시되는지 여부(및 기간)를 제어할 수 있습니다. GraphQL 클라이언트를 사용하여 OSGi 서비스에 대한 캐싱 동작을 정의할 수도 있습니다.

구성

지정된 구성 요소에 대해 구성된 캐시는 각 캐시 구성 항목으로 정의된 대로 GraphQL 쿼리 및 응답 저장을 시작합니다. 캐시의 크기와 각 항목의 캐싱 기간은 예를 들어 다음에 따라 프로젝트 단위로 정의됩니다.

캐시 무효화는 없으므로 캐시 기간을 설정할 때 주의하십시오.

구성 요소에 대한 캐싱을 구성할 때 캐시 이름은 프로젝트에 정의한 프록시 구성 요소의 이름이어야 합니다.

클라이언트가 GraphQL 요청을 보내기 전에 동일한 exact GraphQL 요청이 이미 캐시되었는지 확인하고 캐시된 응답을 반환할 수 있습니다. 일치시키려면 GraphQL 요청 must ​이(가) 정확히 일치해야 합니다. 즉, 쿼리, 작업 이름(있는 경우), 변수(있는 경우) must ​이(가) 모두 캐시된 요청과 같습니다. 또한 must(으)로 설정할 수 있는 모든 사용자 지정 HTTP 헤더도 동일합니다. 예를 들어 Adobe Commerce Store 헤더 must ​이(가) 일치합니다.

예

Adobe은 제품 검색 및 카테고리 페이지에 표시된 사용 가능한 모든 집계/패싯 값을 가져오는 검색 서비스에 대해 일부 캐싱을 구성할 것을 권장합니다. 이러한 값은 일반적으로 예를 들어 제품에 새 특성이 추가될 때만 변경됩니다. 따라서 제품 속성 세트가 자주 변경되지 않는 경우 이 캐시 항목의 지속 시간이 "큼"일 수 있습니다. 이 항목은 프로젝트별로 다르지만, Adobe은 프로젝트 개발 단계에서 몇 분, 안정적인 프로덕션 시스템에서 몇 시간의 값을 권장합니다.

이 설정은 일반적으로 다음 캐시 항목으로 구성됩니다.

GraphQl 캐싱 기능을 사용하는 것이 권장되는 또 다른 예제 시나리오는 탐색 구성 요소입니다. 그 이유는 모든 페이지에서 동일한 GraphQL 쿼리를 보내기 때문입니다. 이 경우 캐시 항목은 일반적으로 다음과 같이 설정됩니다.

Venia 참조 저장소가 사용되는 것을 고려하는 중입니다. 구성 요소 프록시 이름 venia/components/structure/navigation을(를) 사용하고 CIF 탐색 구성 요소(core/cif/components/structure/navigation/v1/navigation)의 이름을 not ​하십시오.

다른 구성 요소에 대한 캐싱은 일반적으로 Dispatcher 수준에서 구성된 캐싱과 함께 프로젝트 기반으로 정의되어야 합니다. 이러한 캐시에 대한 활성 무효화가 없으므로 캐싱 기간을 신중하게 설정해야 합니다. 가능한 모든 프로젝트 및 사용 사례와 일치하는 "한 가지 크기가 모두 맞춤" 값은 없습니다. 프로젝트의 요구 사항과 가장 일치하는 프로젝트 수준에서 캐싱 전략을 정의해야 합니다.