Configurations de réglage du cache à distance dans HCL Cache

Pour plus d'informations sur la façon dont ces paramètres peuvent être appliqués aux caches personnalisés ou par défaut, voir Configuration du cache.

Compression

HCL Cache fournit la possibilité d'utiliser un algorithme de compression, LZ4, sur les valeurs de clé de cache. Les caches avec des clés volumineuses, comme la mise en cache JSP dans baseCache, peuvent bénéficier de la compression. La compression réduit la taille des clés dans Redis et réduit le trafic réseau, mais elle peut augmenter l'utilisation de l'UC sur les conteneurs client. Il se peut que l'activation de la compression sur les caches avec de petites clés ne présente aucun avantage.

cacheConfigs:
  baseCache:
    remoteCache:
      codec: compressing

Partitionnement

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)

Etant donné que chaque fragment est affecté à un emplacement de hachage unique, la fragmentation est généralement utilisée avec la mise en cluster Redis, car elle permet à chaque fragment ou segment de cache d'être géré par un nœud Redis différent. La fragmentation peut être utile pour les caches qui peuvent surcharger un nœud Redis unique, soit en raison de leur encombrement de la mémoire, soit de la quantité de charges/d'opérations qu'ils génèrent. baseCache est un exemple de cache qui peut bénéficier de la fragmentation.

Dans un environnement de cluster Redis, l'affectation d'emplacement est effectuée en tenant compte de l'espace de nom, du nom de cache et du numéro de fragment. Il n'est pas garanti que les fragments seront répartis uniformément sur les nœuds Redis, mais ce problème peut être résolu en augmentant le nombre de fragments ou en utilisant la migration d'emplacements.

Impact de la fragmentation sur les opérations de cache

Obtenir	Placer	Invalider	Effacer
Un algorithme de hachage est appliqué sur la valeur cache-id pour sélectionner le fragment à partir duquel l'entrée de cache doit être extraite. La fragmentation a un impact négligeable sur les opérations "get".	Un algorithme de hachage est appliqué sur la valeur cache-id pour sélectionner le fragment auquel l'entrée de cache sera affectée. La fragmentation a un impact négligeable sur les opérations "put".	Les invalidations doivent être exécutées sur tous les fragments. Cette opération est effectuée en parallèle.	Une opération clear doit être exécutée sur tous les fragments. Cette opération est effectuée en parallèle.

Traitement parallèle des opérations invalidate et clear

Le HCL Cache utilise un pool d'unités d'exécution pour effectuer des opérations de partitionnement invalidate et clear en parallèle. La taille du pool d'unités d'exécution est configurée avec le paramètre numAsyncCacheOperationThreads, qui est configuré au niveau supérieur de la configuration YAML :

numAsyncCacheOperationThreads: -1
cacheConfig:
  ... 

numAsyncCacheOperationThreads est défini par défaut sur -1, ce qui se traduit par le nombre maximal de fragments configurés pour n'importe quel cache.

Lorsqu'une opération invalidate ou clear est exécutée sur un cache fragmenté, HCL Cache tente d'utiliser le pool d'unités d'exécution pour s'exécuter en parallèle. Si le pool d'unités d'exécution n'a pas d'unités d'exécution en file d'attente, tous les fragments seront exécutés simultanément. Si le pool d'unités d'exécution est utilisé et qu'il existe des tâches en file d'attente, le pool d'unités d'exécution n'est pas utilisé et chaque fragment est traité de façon séquentielle. Cela sert à gérer un cas potentiel dans lequel plusieurs opérations invalidate sont exécutées simultanément sur un cache fragmenté, ce qui peut nécessiter l'exécution d'un grand nombre d'unités d'exécution.

Inactivité

L'inactivité est disponible à partir de HCL Commerce version 9.1.10. Elle est désactivée par défaut. La configuration de l'inactivité permet au HCL Cache de suivre et d'évincer les entrées qui ne sont pas réutilisées. En supprimant les entrées inactives avant leur heure d'expiration, la mémoire cache totale utilisée est réduite, ce qui rend l'exécution du cache plus efficace.

Etant donné que le suivi des entrées inactives ajoute un coût de traitement, l'inactivité n'est actuellement pas activée par défaut. Au lieu de cela, il est activé pour les caches par défaut sélectionnés et peut être activé pour d'autres caches par défaut ou personnalisés.

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

Voir Maintenance du cache pour plus de détails sur la façon dont la maintenance de l'inactivité est effectuée et peut être surveillée et réglée.

Utilisation de l'inactivité avec les caches locaux

Les caches locaux prennent en charge l'inactivité au niveau de l'entrée de cache. L'inactivité peut être configurée à l'aide de cachespec.xml, ou par programme avec l'interface DistributedMap. L'inactivité définie par DynaCache est utilisée pour la mise en cache locale uniquement et n'a pas d'impact sur le processus d'inactivité du cache distant, qui doit être activé indépendamment.

Maintenance d'inactivité et maintenance de mémoire faible

Les environnements de production génèrent de grandes quantités de cache. Certains caches, tels que les utilisateurs ou "searchTerm", peuvent devenir sans limite et éventuellement remplir la mémoire cache distante (maxmemory). Lorsque l'utilisation de la mémoire Redis est proche de la limite, la maintenance de mémoire faible déclenche le maintien de l'utilisation sous 100 %. L'utilisation de la maintenance d'inactivité peut éliminer ou réduire le traitement effectué pour la maintenance de mémoire faible. L'utilisation de la maintenance d'inactivité est plus efficace comme suit :

• La maintenance d'inactivité s'exécute en continu, tandis que la maintenance de mémoire faible ne se déclenche que lorsque la mémoire est presque saturée. Le maintien d'un encombrement de mémoire plus faible permet à Redis de s'exécuter plus efficacement, y compris les opérations à haute disponibilité telles que la persistance et la récupération.
• La maintenance de l'inactivité s'exécute à partir de tous les conteneurs, tandis que la maintenance de mémoire faible n'est active qu'à partir d'un seul conteneur à la fois.
• La maintenance de mémoire faible doit supprimer un pourcentage du cache, et cela en sélectionnant des entrées qui vont bientôt arriver à expiration, même si elles peuvent avoir une réutilisation élevée. Toutefois, la maintenance d'inactivité supprime uniquement les entrées inactives, ce qui permet de conserver d'autres entrées à forte réutilisation.

Instruction d'inactivité et ignorer le cache distant

Le HCL Cache a des configurations spéciales appelées instructions de cache qui sont utilisées avec les entrées de cache pour ignorer la mise en cache locale ou distante. Les caches qui activent la mise en cache locale et distante, et qui traitent les entrées qui peuvent ne pas être réutilisées, peuvent bénéficier de ces configurations. Par exemple, les appels REST qui spécifient searchTerm, la création de facettes et la pagination. Les caches qui créent de nombreuses entrées de cache qui ne sont pas réutilisées peuvent être inefficaces. La désactivation de la mise en cache à distance pour ces caches peut aider à réduire l'encombrement de la mémoire cache distante. A partir de HCL Commerce version 9.1.10, vous pouvez choisir d'autoriser ces entrées dans le cache distant, tout en vous appuyant sur le traitement de l'inactivité pour supprimer les entrées inactives.

Mise en cache REST QueryApp pour searchTerm

Le conteneur QueryApp implémente l'instruction skip-remote pour certains caches "searchTerm" dans cachespec.xml. Si vous activez l'inactivité pour baseCache, envisagez d'autoriser ces caches à utiliser le cache distant, en personnalisant le fichier cachespec.xml pour supprimer les fragments suivants :

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

Optimisations pour les opérations d'effacement de cache

Les opérations clear de cache à distance fonctionnent en examinant la base de données Redis et en supprimant toutes les clés qui correspondent au préfixe du cache (par exemple, {cache-demoqalive-baseCache}-*). Cet algorithme est plus efficace avec des caches volumineux ou avec des caches qui représentent un pourcentage élevé du total des clés.

Lors de l'effacement d'un petit cache, l'algorithme doit toujours examiner l'ensemble de la base de données pour rechercher les clés correspondantes. Etant donné que l'opération de cache clear n'est pas bloquante, l'examen peut être lent et nécessiter de nombreux appels au serveur Redis.

Pour les petits caches, il est plus efficace d'utiliser la logique invalidate. La logique invalidate traite chaque entrée de cache et ses ID de dépendance, mais évite l'examen complet de la base de données à l'aide de l'ID de dépendance défini. Pour effectuer un clear, la logique invalidate est exécutée avec l'ID de dépendance implicite &ALL&, qui est associé à toutes les clés du cache.

Le HCL Cache est configuré pour utiliser l'algorithme invalidate pour les effacements de cache avec le paramètre smallCacheClearOptimizationMaximumSize, qui est activé par défaut avec la valeur 50000.

smallCacheClearOptimizationMaximumSize est disponible depuis la version 9.1.6. 

cacheConfigs:
  baseCache:
    remoteCache:
      smallCacheClearOptimizationMaximumSize: 50000