Configuraciones de ajuste de memoria caché remota en HCL Cache

Consulte Configuración de memoria caché para obtener detalles sobre cómo estos valores se pueden aplicar a memorias caché personalizadas o predeterminadas.

Compresión

HCL Cache proporciona la opción de utilizar un algoritmo de compresión, LZ4, en los valores de clave de memoria caché. Las memorias caché con claves grandes, como el almacenamiento en memoria caché JSP en baseCache , pueden beneficiarse de la compresión. La compresión reduce el tamaño de las claves en Redis y reduce el tráfico de red, pero puede aumentar CPU uso en los contenedores de cliente. Es posible que no vea ninguna ventaja al habilitar la compresión en memorias caché con claves pequeñas.

cacheConfigs:
  baseCache:
    remoteCache:
      codec: compressing

Fragmentación

cacheConfigs:
  baseCache:
    remoteCache:
      shards: 3

{cache-demoqalive-baseCache}-invalidation
{cache-demoqalive-baseCache:s=0}-(dep|data)
{cache-demoqalive-baseCache:s=1}-(dep|data)
{cache-demoqalive-baseCache:s=2}-(dep|data)

Dado que a cada fragmento se le asigna una ranura hash exclusiva, la fragmentación se utiliza normalmente con la agrupación en clúster de Redis, ya que permite que un nodo Redis diferente maneje cada segmento de memoria caché o fragmento. La fragmentación puede ser útil para las memorias caché que pueden sobrecargar un único nodo de Redis, ya sea debido a su huella de memoria o a la cantidad de carga/operaciones que generan. baseCache es un ejemplo de una memoria caché que puede beneficiarse de la fragmentación.

En un entorno de clúster de Redis, la asignación de ranura se realiza teniendo en cuenta el espacio de nombres, el nombre de memoria caché y el número de fragmento. No se garantiza que los fragmentos se distribuyan uniformemente entre los nodos de Redis, pero este problema se puede superar aumentando el número de fragmentos o utilizando la migración de ranuras.

Impacto de la fragmentación en las operaciones de memoria caché

Obtener	Enviar	Invalidar	Borrar
Se aplica un algoritmo de hash sobre cache-id para seleccionar el fragmento del que se debe recuperar la entrada de memoria caché. La fragmentación tiene un impacto insignificante en las operaciones "get".	Se aplica un algoritmo de hash sobre cache-id para seleccionar el fragmento al que se asignará la entrada de memoria caché. La fragmentación tiene un impacto insignificante en las operaciones "put".	Las invalidaciones deben ejecutarse en todos los fragmentos. Esto se hace en paralelo.	Debe ejecutarse una operación clear en todos los fragmentos. Esto se hace en paralelo.

Proceso paralelo de operaciones invalidate y clear

HCL Cache utiliza una agrupación de hebra para realizar operaciones de fragmentación invalidate y clear en paralelo. El tamaño de agrupación de hebra se configura con el valor numAsyncCacheOperationThreads, que se configura en el nivel superior de la configuración YAML:

numAsyncCacheOperationThreads: -1
cacheConfig:
  ... 

numAsyncCacheOperationThreads toma el valor predeterminado -1, que se traduce al número máximo de fragmentos configurados para cualquier memoria caché.

Cuando se ejecuta una operación invalidate o clear en una memoria caché fragmentada, HCL Cache intenta utilizar la agrupación de hebras para ejecutarse en paralelo. Si la agrupación de hebra no tiene hebras en cola, todos los fragmentos se ejecutarán simultáneamente. Si la agrupación de hebra está en uso y hay tareas en cola, la agrupación de hebras no se utiliza y cada fragmento se procesa secuencialmente. Esto es para gestionar un caso potencial en el que se ejecutan varias operaciones invalidate simultáneamente en una memoria caché fragmentada, lo que puede requerir que un gran número de hebras estén activas.

Inactividad

La inactividad está disponible desde la versión 9.1.10 HCL Commerce. Está inhabilitado de forma predeterminada. La configuración de inactividad permite a HCL Cache realizar un seguimiento y expulsar entradas que no están viendo la reutilización. Al eliminar entradas desocupadas antes de su tiempo de caducidad, se reduce la memoria caché total utilizada, lo que hace que la memoria caché se ejecute de forma más eficaz.

Dado que el seguimiento de entradas inactivas añade un coste de proceso, la inactividad no está habilitada actualmente de forma predeterminada. En su lugar, está habilitada para las memorias caché predeterminadas seleccionadas y se puede habilitar para otras memorias caché predeterminadas o personalizadas.

cacheConfigs:
  baseCache:
    remoteCache:
      onlineInactiveEntriesMaintenance:
        enabled: true
        inactivityMins: 30

Consulte Mantenimiento de memoria caché para obtener detalles sobre cómo se realiza el mantenimiento de inactividad y cómo se puede supervisar y ajustar.

Uso de la inactividad con memorias caché locales

Las memorias caché locales dan soporte a la inactividad a nivel de entrada de memoria caché. La inactividad se puede configurar utilizando cachespec.xml, o de forma programada con la interfaz DistributedMap . La inactividad establecida por DynaCache se utiliza solo para el almacenamiento en memoria caché local y no afecta al proceso de inactividad de la memoria caché remota, que debe habilitarse de forma independiente.

Inactividad frente a mantenimiento de memoria baja

Los entornos de producción generan grandes cantidades de memoria caché. Ciertas memorias caché, como los usuarios o "searchTerm", pueden crecer sin límites y, finalmente, rellenar la memoria caché remota (maxmemory). Cuando el uso de memoria de Redis está cerca del límite, el mantenimiento de memoria baja se desencadena para mantener el uso por debajo del 100%. El uso del mantenimiento de inactividad puede eliminar o reducir el proceso realizado para el mantenimiento de memoria baja. El uso del mantenimiento de inactividad es más eficaz de la siguiente manera:

• El mantenimiento de inactividad se ejecuta continuamente, mientras que el mantenimiento de memoria baja solo se desencadena cuando la memoria está casi llena. Mantener una huella de memoria más pequeña permite que Redis se ejecute de forma más eficaz, incluidas las operaciones de alta disponibilidad, como la persistencia y la recuperación.
• El mantenimiento de inactividad se ejecuta desde todos los contenedores, mientras que el mantenimiento de memoria baja está activo desde un solo contenedor a la vez.
• El mantenimiento de memoria baja debe eliminar un porcentaje de la memoria caché, y lo hace seleccionando entradas que han caducado antes, incluso si pueden tener una reutilización alta. Sin embargo, el mantenimiento de inactividad solo elimina entradas inactivas, lo que ayuda a retener otras entradas de alta reutilización.

Directiva de memoria caché remota y de inactividad

HCL Cache tiene configuraciones especiales denominadas directivas de memoria caché que se utilizan con entradas de memoria caché para omitir el almacenamiento en memoria caché local o remota. Las memorias caché que habilitan el almacenamiento en memoria caché local y remota, y tratan con entradas que pueden no ver la reutilización, pueden beneficiarse de estas configuraciones. Algunos ejemplos incluyen llamadas REST que especifican searchTerm, facetas y paginación. Las memorias caché que crean muchas entradas de memoria caché que no se reutilizan pueden ser ineficaces. La inhabilitación del almacenamiento en memoria caché remota para esas memorias caché puede ayudar a reducir la implementación de memoria caché remota. Desde HCL Commerce la versión 9.1.10, puede optar por permitir estas entradas en la memoria caché remota, a la vez que se basa en el proceso inactividad para eliminar entradas inactivas.

Almacenamiento en memoria caché de queryApp REST para searchTerm

El contenedor QueryApp implementa la directiva skip-remote para determinadas memorias caché "searchTerm" en cachespec.xml. Si habilita Inactivity para baseCache, considere la posibilidad de permitir que estas memorias caché utilicen la memoria caché remota, personalizando el archivo cachespec.xml para eliminar los fragmentos de código siguientes:

<component id="DC_HclCacheSkipRemote" type="attribute">
  <required>true</required>
</component>

Optimizaciones para operaciones de borrado de memoria caché

Las operaciones de memoria caché clear remota funcionan escaneando la base de datos de Redis y suprimiendo todas las claves que coinciden con el prefijo de memoria caché (por ejemplo, {cache-demoqalive-baseCache}-*). Este algoritmo es más eficaz con memorias caché grandes o con memorias caché que representan un gran porcentaje de las claves totales.

Al borrar una memoria caché pequeña, el algoritmo debe seguir explorando toda la base de datos en busca de claves coincidentes. Puesto que la operación de memoria caché clear no es de bloqueo, el escaneo puede ser lento y requerir muchas llamadas al servidor Redis.

Para memorias caché pequeñas, es más eficaz utilizar la lógica invalidate. La lógica invalidate procesa cada entrada de memoria caché y sus IDs de dependencia, pero evita la exploración de base de datos completa utilizando el conjunto de ID de dependencia. Para realizar un clear, la lógica invalidate se ejecuta con el ID de dependencia implícito &ALL&, que está asociado con todas las claves de la memoria caché.

HCL Cache se configura para utilizar el algoritmo invalidate para borrar memoria caché con el valor smallCacheClearOptimizationMaximumSize, que está habilitado de forma predeterminada con un valor de 50000.

smallCacheClearOptimizationMaximumSize está disponible desde la versión 9.1.6.

cacheConfigs:
  baseCache:
    remoteCache:
      smallCacheClearOptimizationMaximumSize: 50000