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 configuration
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 lo siguiente:
- La frecuencia con la que pueden cambiar los datos del catálogo.
- Qué importancia tiene que un componente siempre muestre los datos más recientes posibles, etc.
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 esa exacta 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 las hay) deben ser iguales a la solicitud en caché. Además, todos los encabezados HTTP personalizados que se establezcan deben ser iguales. Por ejemplo, el encabezado must de Adobe Commerce Store debe coincidir.
Ejemplos examples
El Adobe recomienda configurar el almacenamiento en caché para el servicio de búsqueda que recupere 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 se añade un nuevo atributo a los productos, por ejemplo. Por lo tanto, la duración de esta entrada de caché puede ser "grande" si el conjunto de atributos de producto no cambia con frecuencia. Aunque esta entrada es específica del 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.
Esta configuración 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 función de almacenamiento en caché GraphQl es el componente de navegación. El motivo es que envía la misma consulta de 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
Teniendo en cuenta que se usa la Tienda de referencia de Venia. 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. AEM Esta función es fundamental para la estrategia de almacenamiento en caché de Dispatcher de la.
AEM CIF Además de la gestión pura de contenido por parte de los usuarios, una página puede mostrar, por lo general, 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 los datos del producto, como el nombre y el precio, cambian en Adobe Commerce.
CIF AEM Para asegurarse de que las páginas de la se almacenen en caché durante un tiempo limitado en el Dispatcher de la, la Adobe CIF AEM recomienda utilizar Invalidación de caché basada en tiempo (conocida como caché basada en TTL) al almacenar en caché páginas de la en el Dispatcher. 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 Esta duración 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.
product, productlist y searchresults, generalmente recuperan los precios de los productos en una solicitud del explorador del lado del cliente cuando se carga la página. Al hacerlo, se garantiza que el contenido dinámico crucial siempre se obtenga al cargar la página.