Mise en cache et invalidation dans HCL Commerce Search

Le cache de fragments JSP et le cache d'objets de données peuvent être utilisés avec le serveur de recherche pour la mise en cache et l'invalidation. Le cache de fragments JSP est utilisé sur le serveur HCL Commerce pour mettre en cache des parties de l'interface utilisateur de vitrine pour une réutilisation ultérieure. Le cache d'objets de données est utilisé sur le serveur de recherche pour stocker les propriétés d'exécution internes utilisées par certaines fonctions de recherche pour améliorer les performances globales.

Pour éviter la mise en cache excessive et un excès de contenu mis en cache, les opérations de recherche ne sont généralement pas mises en cache. Les recommandations générales consistent à de ne pas mettre en cache les réponses pleine page lorsqu'un mot clé est spécifié dans la requête d'origine. Cette approche est également utilisée pour gérer la navigation à facettes dans la vitrine.

Etant donné que le contenu personnalisé ou les données volatiles, telles que le niveau de prix ou de stock, peuvent apparaître sur certaines pages mises en cache, vous pouvez désactiver la mise en cache d'un fragment de page. Pour atteindre ce résultat, utilisez la mise en cache de fragments. Pour plus d'informations, voir HCL Commerce Search mise en cache.

Une fois qu'une stratégie de cache est définie dans le fichier cachespec.xml d'une page JSP, les propriétés DynaCache invalidation for storefront cached content sont utilisées dans le fichier de configuration de composant de catalogue (wc-component.xml). Pour plus d'informations, voir Propriétés de recherche dans le fichier de configuration de composant (wc-component.xml).

Invalidation des données en mémoire cache

Etant donné qu'un léger retard se produit entre la synchronisation de l'index de recherche et les dernières modifications de la base de données, des considérations doivent être prises en compte lorsque vous invalidez un contenu mis en cache pour la navigation dans un catalogue basé sur la recherche. Ces retards peuvent être dus à une propagation du transfert ou à une publication immédiate lorsque vous appliquez un correctif d'urgence.

L'invalidation du cache de vitrine est effectuée automatiquement lorsque vous utilisez Propagation de transfert et Publication immédiate pour les correctifs d'urgence. Lorsque la réplication d'index est terminée, une instruction d'invalidation du cache est émise en insérant une entrée de type restart dans la table CACHEIVL. L'entrée utilise le paramètre d'heure de début fourni en temps qu'heure de démarrage de l'invalidation du cache. La commande du planificateur DynaCacheInvalidation effectue la même invalidation, à partir du paramètre d'heure de début. Ce planificateur empêche l'invalidation précoce, ce qui entraînerait une nouvelle mise en cache du contenu obsolète avant que les dernières modifications d'index ne deviennent disponibles. Les entrées d'invalidation dans la table CACHEIVL peuvent être des ID de dépendance utilisés pour l'invalidation du cache de fragments JSP ou l'invalidation du cache d'objets de données.

Ces considérations sont basées sur les scénarios suivants :Lorsqu'un répéteur d'index est utilisé pour capturer le contenu de l'index le plus récemment déployé et sert de sauvegarde pour les cibles de production.

Le répéteur prend du temps pour reproduire les modifications de l'index sur tous ses serveurs subordonnés. L'ensemble de la navigation de catalogue basée sur la recherche est récupérée par les serveurs subordonnés de l'environnement de production, et non pas par le répéteur. Par conséquent, si l'invalidation du cache se produit immédiatement après les modifications de la base de données, et pendant que la réplication de l'index de recherche est toujours en cours, le nouveau contenu du cache peut encore ne pas être exact. L'index de recherche contient toujours les anciennes données. La recréation immédiate du nouveau cache peut entraîner la réutilisation des anciennes données.

Les éléments suivants doivent être pris en compte pour déterminer un délai approprié, en millisecondes, avant que l'invalidation du cache ne se produise après chaque réindexation de recherche :
  • L'heure à laquelle la prochaine commande de réindexation du planificateur est lancée.
  • Le temps approximatif que la réindexation pourrait prendre pour s'achever.
  • Le temps de réplication suivant entre l'index de recherche de production et le répéteur.
  • Le temps approximatif que la réplication de l'index pourrait prendre pour s'achever.
Lorsque la somme des estimations de temps est égale au délai approximatif nécessaire avant que l'invalidation du cache puisse avoir lieu.