Almacenamiento en caché y rendimiento caching

Almacenamiento en caché de respuestas de GraphQL y componentes graphql

Los componentes principales del CIF de AEM ya cuentan con una compatibilidad integrada para almacenar en caché las respuestas de GraphQL para los componentes individuales. Esta función se puede utilizar para reducir en gran medida el número de llamadas de back-end de GraphQL. Se puede lograr un almacenamiento en caché efectivo, especialmente para las consultas repetidas como recuperar el árbol de categorías de un componente de navegación o recuperar todos los valores de facetas/acumulados disponibles que se muestran en las páginas de categoría y búsqueda de productos.

Para los componentes principales del CIF de AEM, el almacenamiento en caché se configura en base a componentes, por lo que es posible controlar si (y durante cuánto tiempo) las solicitudes/respuestas de GraphQL se almacenan en la caché para cada componente. También es posible definir el comportamiento del almacenamiento en caché para los servicios OSGi mediante el cliente de GraphQL.

Configuración

Una vez configurada para un componente determinado, los inicios de caché almacenan las consultas y respuestas de GraphQL según se define en cada entrada de configuración de caché. El tamaño de la caché y la duración de almacenamiento en caché de cada entrada se definen en función del proyecto, por ejemplo en función de la frecuencia con la que cambien los datos del catálogo, la importancia de que un componente siempre muestre los datos más recientes posibles, etc. Tenga en cuenta que no hay ninguna invalidación de caché, por lo que tenga cuidado al configurar las duraciones de la caché.

Al configurar el almacenamiento en caché para los componentes, el nombre de la caché debe ser el nombre de los componentes proxy que defina en el proyecto.

Antes de que el cliente envíe una solicitud de GraphQL, comprueba si es así exacto La misma solicitud de GraphQL ya se ha almacenado en caché y posiblemente devuelva la respuesta almacenada en caché. Para coincidir, la solicitud de GraphQL DEBE coincidir exactamente, es decir, la consulta, el nombre de la operación (si existe), las variables (si existe) DEBEN ser iguales a la solicitud en caché, y también todos los encabezados HTTP personalizados que se establezcan DEBEN ser iguales. Por ejemplo, Adobe Commerce Store El encabezado DEBE coincidir.

Ejemplos

Se recomienda configurar el almacenamiento en caché para el servicio de búsqueda que recoge todos los valores de acumulados y facetas disponibles que se muestran en las páginas de categoría y búsqueda de productos. Estos valores solo cambian normalmente cuando, por ejemplo, se añade un nuevo atributo a los productos, por lo que la duración de esta entrada de caché puede ser "grande" si el conjunto de atributos de producto no cambia con frecuencia. Aunque esto es específico para cada proyecto, el Adobe recomienda valores de unos minutos en las fases de desarrollo del proyecto y unas pocas horas en los sistemas de producción estables.

Esto suele configurarse con la siguiente entrada de caché:

com.adobe.cq.commerce.core.search.services.SearchFilterService:true:10:3600

Otro escenario de ejemplo en el que se recomienda utilizar la funcionalidad de almacenamiento en caché GraphQl es el componente de navegación, ya que envía la misma consulta GraphQL a todas las páginas. En este caso, la entrada de caché se configuraría normalmente en:

venia/components/structure/navigation:true:10:600

Cuando se considere la Tienda de referencia de Venia se utiliza. Tenga en cuenta el uso del nombre del proxy del componente venia/components/structure/navigation, y no el nombre del componente de navegación de CIF (core/cif/components/structure/navigation/v1/navigation).

El almacenamiento en caché de otros componentes debe definirse sobre la base de un proyecto, normalmente en coordinación con el almacenamiento en caché configurado a nivel de Dispatcher. Recuerde que no hay ninguna invalidación activa de estas memorias caché, por lo que la duración del almacenamiento en caché debe configurarse cuidadosamente. No hay valores "únicos" que coincidan con todos los proyectos y casos de uso posibles. Asegúrese de definir una estrategia de almacenamiento en caché en el nivel de proyecto que se ajuste mejor a los requisitos del proyecto.

Almacenamiento en caché de Dispatcher dispatcher

El almacenamiento en caché de páginas de AEM o fragmentos en AEM Dispatcher es una práctica recomendada para cualquier proyecto AEM. Generalmente, se basa en técnicas de invalidación que garantizan que cualquier cambio de contenido en AEM se actualice correctamente en Dispatcher. Esta es una característica central de la estrategia de almacenamiento en caché de AEM Dispatcher.

AEM CIF Además del contenido administrado puramente por el usuario, una página generalmente puede mostrar datos de comercio que se recuperan dinámicamente desde Adobe Commerce a través de GraphQL. Aunque la estructura de la página en sí podría no cambiar nunca, el contenido comercial podría cambiar, por ejemplo, si algunos datos del producto (como nombre o precio) cambian en Adobe Commerce.

CIF AEM Por lo tanto, para asegurarse de que las páginas en la caché se pueden almacenar durante una cantidad de tiempo limitada en la caché de Dispatcher, se recomienda el uso de la variable Invalidación de caché basada en tiempo CIF AEM (también conocido como almacenamiento en caché basado en TTL) al almacenar en caché páginas de la de Dispatcher de la aplicación de almacenamiento en caché. Esta función se puede configurar en AEM usando el paquete adicional ACS AEM Commons.

Con el almacenamiento en caché basado en TTL, un desarrollador suele definir una o varias duraciones de almacenamiento en caché para páginas de AEM seleccionadas. CIF AEM Esto garantiza que las páginas de la solo se almacenen en caché en Dispatcher hasta la duración configurada y que el contenido se actualice con frecuencia.

NOTE
AEM CIF Aunque Dispatcher puede almacenar en caché los datos del lado del servidor, algunos componentes del lado del servidor de Dispatcher de la, como el product, productlist, y searchresults normalmente, los componentes siempre recuperan los precios del producto en una solicitud del explorador del lado del cliente cuando se carga la página. Esto garantiza que el contenido dinámico crucial siempre se obtenga al cargar la página.

Recursos adicionales

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2