Stratégie de mise en cache

Mise en cache des pages de serveur locale (Transaction)

Quelles pages mettre en cache ?

Les bons candidats à la mise en cache sont les pages Web qui :

• Sont fréquemment affichées.
• Sont stables au fil du temps.
• Contiennent une majorité de données pouvant être réutilisées par différents utilisateurs.

Les pages de catalogue présentent, par exemple, ce type de caractéristiques.

Où la mise en cache doit-elle se produire ?

En théorie, la mise en cache a lieu au niveau le plus proche de l'utilisateur. En réalité, d'autres facteurs tels que la sécurité et des données spécifiques aux utilisateurs peuvent influer sur le choix de l'emplacement le plus adapté à la mise en cache du contenu. Afin de tirer le meilleur parti d'une mise en cache dynamique, il est possible de fragmenter les éléments d'une page de façon aussi fine que possible de sorte qu'ils puissent être mis en cache de manière indépendante dans différentes entrées.

Par exemple, les fragments qui ne sont pas spécifiques à un utilisateur ou qui ne sont pas sensibles sur le plan de la sécurité, sont généralement utiles à de nombreux utilisateurs, et peuvent donc être mis en cache dans un espace accessible à un plus large public et plus proche de l'utilisateur. Les données sensibles de sécurité peuvent être mises en cache derrière le pare-feu de l'entreprise.

Pour les magasins qui s'exécutent sur le serveur de transactions, la mise en cache en dehors de WebSphere Application Server peut être utilisée avec des bases de données et des sites plus volumineux pour améliorer les performances. Un serveur d'équilibrage des charges (Edge Server) et le plug-in de cache ESI sont fournis avec WebSphere Application Server afin d'offrir des possibilités supplémentaires de mise en cache. Les informations de session (ID de langue, ID de devise préférée, organisation parent, ID de contrat et groupe de membres) doivent être stockées dans des cookies de session. Les cookies sont nécessaires pour la mise en cache sur un serveur externe à WebSphere Application Server.

Mise en cache de pages entières ou de fragments de page

Toutes les pages Web se composent de fragments plus petits et plus simples. Un en-tête, une barre d'options latérale, un bas de page ou un élément an e-marketing sont considérés comme des fragments de page. La décomposition en fragments ou en composants d'une page Web facilite la mise en cache d'une page, même d'une page personnalisée. Les fragments peuvent être autant que possible réutilisables.

La mise en cache d'une page Web complète consiste à mettre en cache la page entière en tant que grosse entrée de cache incluant le contenu de tous les fragments de page sans inclusions ni réacheminements. Cette approche peut diminuer considérablement le traitement par le serveur d'applications mais il est généralement utile lorsque la requête HTTP externe contient toutes les informations nécessaires à la recherche de l'entrée.

Lorsque des pages Web sont scindées en différents fragments et que ces derniers sont mis en cache de manière individuelle, certains peuvent être réutilisées pour un plus large public. Lorsqu'une page Web est appelée, ses différents fragments sont ainsi rassemblés pour générer une page. Pour plus d'informations, voir Mise en mémoire cache de pages complètes et de fragments.

Si le résultat de la page comporte des sections dépendantes de l'utilisateur, ce résultat est mis en cache selon la méthode appelée mise en cache de fragments. Dans ce cas, les pages JSP sont mises en cache en tant qu'entrées séparées et sont reconstituées lorsqu'elles sont appelées. Si la page générée produit toujours le même résultat en fonction des paramètres de l'URL et des attributs de requête, cette page générée peut être mise en cache avec cache-entry. Utilisez la propriété consume-subfragments (CSF) et le servlet de contrôleur de magasin de HCL Commerce (com.ibm.commerce.struts.ECActionServlet pour HCL Commerce version 9.0.0.x, ou com.ibm.commerce.struts.v2.ECActionServlet pour la version 9.0.x) comme nom de servlet.

Les pages Web peuvent être mises en cache dans leur intégralité et/ou par fragments.

Mise en cache de pages de serveurs distantes (Store)

Si vous utilisez des magasins distants qui s'exécutent sous le profil WebSphere Liberty, votre stratégie de mise en cache doit être modifiée pour refléter la conteneurisation des serveurs de transaction et de recherche. En particulier, vous devez mettre en cache les résultats des appels REST différemment.

Quelles pages mettre en cache ?

Votre sélection de pages à mettre en cache est en grande partie similaire pour les stratégies locales et distantes. Mis à part le cache servlet, un cache de serveur de magasin distant contient non seulement le résultat de rendu JSP/Servlet, mais aussi le résultat d'accès REST distant. N'oubliez pas que les appels qui étaient auparavant locaux dans les topologies de magasin local sont maintenant des appels distants. Par conséquent, il y a deux éléments à prendre en compte. Vous devez toujours fournir des temps de réponse rapides aux appels à partir du navigateur client, mais vous devez également réduire au minimum le nombre d'appels qui sont transmis aux serveurs distants. Vous pouvez mettre en cache le contenu fréquemment extrait des serveurs de transaction ou de recherche, tels que le rendu des résultats et des résultats REST pour les requêtes distantes courantes.

Où la mise en cache doit-elle se produire ?

Réfléchissez à mettre en cache les résultats de balise REST. Si le résultat REST est neutre en matière d'utilisateur, de sécurité ou d'environnement, il est alors un candidat pour la mise en cache dans le cache de résultats REST. Vous pouvez utiliser l'attribut de balise wcf:rest "cached" pour déclarer que le résultat d'un appel peut être mis en cache.

Procédure d'invalidation des données en cache

Vous pouvez déclencher l'invalidation du cache passivement ou activement. L'invalidation passive utilise le paramètre Time To Live (TTL) des entrées de cache pour les pages Web et les fragments pour déclencher l'action. Une fois le temps TTL expiré, le conteneur de données de cache déclenchera l'invalidation du cache. Cette configuration fonctionne mieux lorsque vous définissez le TTL au niveau des pages Web entières et actualisez le cache quotidiennement. Lorsque vous utilisez le paramètre TTL, toute logique personnalisée que vous créez est remplacée par l'expiration du cache.

L'invalidation active peut être déclenchée par des événements que vous définissez dans le fichier de configuration cachespec.xml du serveur. Toutefois, les modifications apportées au fichier d'un serveur ne sont pas automatiquement propagées aux autres serveurs. Si vous utilisez le moteur de recherche Solr avec HCL Commerce version 9.0.x, Apache Kafka est utilisé comme infrastructure de messagerie par défaut pour propager les fichiers. Vous pouvez créer un canal de facto en écrivant la commande d'invalidation dans la table CACHEIVL, accessible à tous les serveurs. Cette approche n'est pas aussi rapide qu'un véritable canal de commande.

Si vous utilisez Elasticsearch avec HCL Commerce version 9.1, votre solution de mise en cache est Redis. Vous pouvez surveiller et contrôler Redis à l'aide du gestionnaire de cache, comme décrit dans HCL Cache. Pour plus d'informations sur la mise en cache et l'invalidation dans Elasticsearch, HCL Cache avec Redis voir.

Pour plus d'informations sur la configuration d'Apache Kafka, voir Invalidation de cache à l'aide de Kafka et ZooKeeper.

Si vous utilisez WebSphere eXtreme Scale comme conteneur de données de cache centralisé, l'invalidation du cache est également centralisée. Dans ce cas, vous n'avez pas besoin d'utiliser un système de messagerie distinct comme Kafka.