Estrategia del almacenamiento en memoria caché

Cuando planifique una estrategia de almacenamiento en memoria caché para HCL Commerce , cuestiones como, por ejemplo, qué páginas se almacenarán en memoria caché y en dónde se almacenarán dentro de la memoria caché son muy importantes. Estas decisiones también dependen de si almacena en memoria caché un servidor local (de transacción) o un servidor remoto (de tienda). Como apoyo ante estas decisiones, tenga en cuenta los siguientes métodos.

Almacenamiento en memoria caché de páginas de servidores locales (de transacción)

Al almacenar en memoria caché de manera local, evalúe las consideraciones siguientes:
  • Qué páginas brindan una mayor mejora en el rendimiento si se almacenan en memoria caché.
  • En dónde se producirá el almacenamiento en memoria caché.
  • Si se almacena en la memoria caché páginas enteras o fragmentos de páginas.
  • Cómo invalidar los datos en memoria caché.

Qué páginas almacenar en memoria caché

Los mejores candidatos para su almacenamiento en la memoria caché son las páginas web que:

  • Son de acceso frecuente.
  • Son estables a lo largo del tiempo.
  • Varios usuarios pueden reutilizar la mayor parte del contenido.

Un buen ejemplo serían las páginas de visualización de catálogo.

Dónde se producirá el almacenamiento en memoria caché

Teóricamente, el almacenamiento en memoria caché debe tener lugar en el nivel que se encuentra más cerca del usuario. En realidad, otros factores como la seguridad y los datos específicos del usuario pueden influir en la elección del mejor lugar para almacenar el contenido en la memoria caché. Para maximizar los beneficios del almacenamiento en la memoria caché dinámica, los elementos de una página deben fragmentarse en trozos tan pequeños como sea posible, de forma que se puedan almacenar en la memoria caché independientemente en distintas entradas de memoria caché.

Por ejemplo, los fragmentos que no son específicos de usuario ni afectan a la seguridad, normalmente son útiles para muchos usuarios y se pueden almacenar en memoria caché en un espacio más público y más próximo al usuario. Los datos confidenciales pueden almacenarse en la memoria caché detrás del cortafuegos de la empresa.

Para las tiendas que se ejecutan en el servidor de transacciones, el almacenamiento en memoria caché fuera de WebSphere Application Server se puede utilizar con sitios y bases de datos de mayor tamaño para mejorar el rendimiento. Edge Server y el plugin de memoria caché ESI se proporcionan con WebSphere Application Server para ofrecer una posibilidad de almacenamiento en memoria caché adicional. En este caso, las cookies son útiles para almacenar la información de sesión, por ejemplo ID de idioma, ID de moneda preferida, organización padre, ID de contrato y grupo de miembros. Las cookies son necesarias para que el almacenamiento en memoria caché se lleve a cabo en un servidor externo a WebSphere Application Server.

Almacenar en la memoria caché páginas enteras o fragmentos de páginas

Todas las páginas web constan de fragments más pequeños y, a menudo, más simples. Un ejemplo del fragmento de una página podría ser una cabecera, una barra lateral, un pie de página o una zona de e-Marketing. Al dividir una página web en fragmentos o componentes, existen más posibilidades de almacenamiento en memoria caché para cada página, incluso para las páginas personalizadas. Los fragmentos pueden diseñarse para maximizar su reutilización.

El almacenamiento en memoria caché de una página web completa significa que se almacena la página entera como una gran entrada de memoria caché, la cual incluye todo el contenido de todos los fragmentos que no tienen inclusiones ni reenvíos. Este método puede ahorrar una carga importante de procesamiento por parte del servidor de aplicaciones y normalmente solo es útil cuando una solicitud HTTP externa contiene toda la información necesaria para encontrar la entrada.

Si las páginas web se dividen en distintos fragmentos y éstos se almacenan en la memoria caché individualmente, es posible que un mayor número de personas pueda reutilizar algunos fragmentos. Cuando se solicita una página web, se vuelven a ensamblar los distintos fragmentos para generar la página. Para obtener más información, consulte Almacenamiento en memoria caché de páginas completas y fragmentos.

Si la salida de página tiene secciones que son dependientes del usuario, la salida de página se almacena en memoria caché de un modo conocido como almacenamiento en memoria caché de fragmentos. Es decir, las páginas JSP se almacenan en memoria caché como entradas independientes y se vuelven a juntar cuando se solicitan. Si la salida de página produce siempre el mismo resultado a partir de los parámetros de URL y los atributos de solicitud, esta salida se puede almacenar en la memoria caché con la entrada de memoria caché (cache-entry). Utilice la propiedad consume-subfragments (CSF) y el servlet del controlador de la tienda de HCL Commerce (com.ibm.commerce.struts.ECActionServlet para la versión 9.0.0.x de HCL Commerce, o com.ibm.commerce.struts.v2.ECActionServlet para la versión 9.0.x) como nombre del servlet.

Las páginas web se pueden almacenar en la memoria caché al utilizar el almacenamiento en memoria caché de página completa o de fragmentos, o se puede utilizar una combinación de ambos métodos.

Almacenamiento en memoria caché de páginas de servidor remoto (tienda)

Si utiliza tiendas remotas que se ejecutan bajo el perfil de WebSphere Liberty, la estrategia de almacenamiento en memoria caché debe cambiar para reflejar la inclusión de los servidores de transacciones y de búsqueda. En concreto, necesita almacenar en memoria caché de una forma diferente los resultados de las llamadas de REST.

Qué páginas se almacenaron en la memoria caché

Su selección de páginas para almacenar en la memoria caché es muy similar para las estrategias locales y remotas. Además de la memoria caché del servlet, la memoria caché de un servidor de tienda remoto no solo contiene el resultado de representación de JSP/Servlet, sino también el resultado de acceso remoto REST. Es importante tener en cuenta que las llamadas que eran locales en las topologías de tienda locales, son ahora llamadas remotas. Por lo tanto, debe tener en cuenta dos cosas. Es necesario que todavía proporcione tiempos de respuesta rápidos a las llamadas realizadas desde el navegador del cliente, pero también debe minimizar el número de llamadas que se pasa a los servidores remotos. Puede almacenar en memoria caché el contenido que a menudo se capta en los servidores de transacción o búsqueda; por ejemplo los resultados de representación y los resultados REST de consultas remotas comunes.

Dónde se produce el almacenamiento en memoria caché

Considere la posibilidad de almacenar en memoria caché los resultados de etiquetas REST. Si el resultado de REST es neutro en cuanto al usuario, la seguridad o el entorno, entonces el elemento es un candidato para almacenarse en la memoria caché del resultado REST. Puede utilizar el atributo de la etiqueta wcf:rest "almacenado en memoria caché" para declarar que el resultado de una llamada se puede almacenar en la memoria caché.

Cómo invalidar los datos en memoria caché

Puede desencadenar la invalidación de la memoria caché de forma pasiva o activa. La invalidación pasiva utiliza el parámetro de tiempo de vida (TTL) de las entradas en la memoria caché de páginas y fragmentos web para desencadenar la acción. Una vez transcurrido el tiempo de vida, el contenedor de datos de la memoria caché desencadenará la invalidación de la memoria caché. Esta configuración funciona mejor cuando se establece el TTL en el nivel de las páginas web completas y se renueva diariamente la memoria caché. Cuando se utiliza el parámetro TTL, la lógica personalizada que se crea se modifica temporalmente debido a la caducidad de la memoria caché.

La invalidación activa puede desencadenarse a través de eventos que se definen en el archivo de configuración cachespec.xml del servidor. Sin embargo, los cambios en el archivo de un servidor no se propagan automáticamente a los demás servidores. Si utiliza un motor de búsqueda de Solr con la versión 9.0.x de HCL Commerce, se utiliza Apache Kafka como la infraestructura de mensajería predeterminada para propagar los archivos. Puede crear un conducto de facto al escribir el mandato de invalidación en la tabla CACHEIVL, a la que acceden todos los servidores. Este método no es tan rápido como utilizar un mandato de conducto real.

Si utiliza Elasticsearch con la versión 9.1 de HCL Commerce, la solución de almacenamiento en memoria caché es Redis. Puede monitorizar y controlar Redis utilizando el Gestor de memoria caché, tal y como se describe en HCL Cache. Para obtener información sobre el almacenamiento en memoria caché y la invalidación en Elasticsearch, consulte HCL Cachecon Redis.

Para obtener más información sobre la configuración de Apache Kafka, consulte Invalidación de memoria caché con Kafka y ZooKeeper.

De forma alternativa, si utiliza WebSphere eXtreme Scale como contenedor de datos centralizado para la memoria caché, la invalidación de memoria caché también se centraliza. En este caso, no es necesario utilizar un sistema de mensajería independiente como, por ejemplo, Kafka.