Ce document expliquera comment la mise en cache du répartiteur se déroule et comment la configurer.
Mise en cache des répertoires
Nous utilisons les répertoires du cache par défaut suivants dans nos installations de la ligne de base.
- Auteur
- /mnt/var/www/author
- Éditeur
- /mnt/var/www/html
Les requêtes qui sont transmises au répartiteur suivent les règles configurées pour conserver une version mise en cache localement en réponse aux éléments éligibles.
Nous gardons intentionnellement la charge de travail publiée séparée de la charge de travail de l’auteur. En effet, quand Apache cherche un fichier dans DocumentRoot, il ne sait pas de quelle instance AEM il provient. Ainsi, même en cas de désactivation du cache dans la ferme de l’auteur, si le DocumentRoot de l’auteur est le même que celui de l’éditeur, il distribuera les fichiers du cache s’il y en a. En d’autres termes, vous distribuerez les fichiers de l’auteur à partir du cache publié et obtiendrez ainsi des résultats de mélange et d’association vraiment déplorables pour vos visiteurs.
Garder des répertoires DocumentRoot séparés pour différents contenus publiés est également une très mauvaise idée. Vous devrez créer plusieurs éléments remis en cache qui ne diffèrent pas d’un site à l’autre, comme les bibliothèques clientes, et vous devrez également configurer un agent de réplication (purge) pour chaque DocumentRoot configuré. Augmenter davantage l’intensité de la purge à chaque activation de page. Compter sur l’espace de nommage des fichiers et leurs chemins d’accès complets en cache et éviter de multiplier les DocumentRoot pour les sites publiés.
Fichiers de configuration
Le Dispatcher contrôle ce qui peut être mis en cache dans la section /cache { de n’importe quel fichier de ferme. Dans les fermes de configuration de la ligne de base AMS, vous trouverez nos inclusions comme indiqué ci-dessous :
/cache {
/rules {
$include "/etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any"
}
Lors de la création des règles indiquant ce qu’il faut mettre en cache ou non, veuillez vous référer à la documentation ici
Auteur de la mise en cache
Dans de nombreuses implémentations, nous avons constaté que les utilisateurs ne mettent pas en cache le contenu des auteurs. Ils passent à côté d’une énorme amélioration des performances et de la réactivité vis-à-vis de leurs auteurs.
Parlons de la stratégie adoptée pour configurer notre ferme d’auteurs de manière à ce qu’elle mette en cache correctement.
Voici une section d’auteur de base /cache { du fichier de notre ferme d’auteurs :
/cache {
/docroot "/mnt/var/www/author"
/statfileslevel "2"
/allowAuthorized "1"
/rules {
$include "/etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any"
}
/invalidate {
/0000 {
/glob "*"
/type "allow"
}
}
/allowedClients {
/0000 {
/glob "*.*.*.*"
/type "deny"
}
$include "/etc/httpd/conf.dispatcher.d/cache/ams_author_invalidate_allowed.any"
}
}
Ce qui est important de souligner ici, c’est que le paramètre /docroot est défini sur le répertoire du cache de l’auteur.
Assurez-vous que votre DocumentRoot du fichier .vhost de l’auteur correspond au paramètre /docroot de la ferme.
L’instruction d’inclusion des règles de mise en cache inclut le fichier /etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any qui contient ces règles :
/0000 {
/glob "*"
/type "deny"
}
/0001 {
/glob "/libs/*"
/type "allow"
}
/0002 {
/glob "/libs/*.html"
/type "deny"
}
/0003 {
/glob "/libs/granite/csrf/token.json"
/type "deny"
}
/0004 {
/glob "/apps/*"
/type "allow"
}
/0005 {
/glob "/apps/*.html"
/type "deny"
}
/0006 {
/glob "/libs/cq/core/content/welcome.*"
/type "deny"
}
Dans un scénario d’auteur, le contenu change en permanence et délibérément. Vous ne voulez mettre en cache que les éléments qui ne vont pas changer régulièrement. Nous avons des règles à mettre en cache dans /libs car elles font partie de l’installation AEM de la ligne de base et changeraient jusqu’à ce que vous ayez installé un Service Pack, un Cumulative Fix Pack, une mise à niveau ou un correctif. Ainsi, la mise en cache de ces éléments est logique et présente d’énormes avantages par rapport à l’expérience d’auteur des utilisateurs finaux qui ont recours à ce site.
Rappelez-vous que ces règles mettent également en cache /apps, qui est l’emplacement où se trouve le code de l’application personnalisé. Si vous développez votre code sur cette instance, il se révélera très confus lorsque vous enregistrerez votre fichier. Vous ne verrez pas s’il se répercute sur l’interface utilisateur car il contient une copie en cache. Dans le cas d’un déploiement de votre code dans AEM, le but est que celui-ci soit peu fréquent et qu’une partie de vos étapes de déploiement consiste à vider le cache de l’auteur. Encore une fois, les avantages sont considérables, car cela permet d’accélérer l’exécution de votre code pouvant être mis en cache pour les utilisateurs finaux.
ServeOnStale (alias Serve on Stale / SOS)
Voici l’un des fleurons de la fonction du répartiteur. Si l’éditeur est en charge ou ne répond plus, il affichera généralement un code de réponse HTTP 502 ou 503. Si cela se produit et que cette fonction est activée, le répartiteur recevra l’instruction de continuer à diffuser, dans la mesure du possible, le contenu encore dans le cache, même s’il ne s’agit pas d’une nouvelle copie. Il est préférable de diffuser du contenu existant plutôt que de simplement afficher un message d’erreur qui n’offre aucune fonctionnalité.
Si le moteur de rendu de l’éditeur affiche un dépassement de délai du socket ou un message d’erreur 500, cette fonction ne se déclenche pas. Si AEM n’est tout simplement pas accessible, cette fonction est inutilisable.
Ce paramètre peut être défini dans n’importe quelle ferme, mais il est conseillé de l’appliquer uniquement aux fichiers de la ferme publiée. Voici un exemple de syntaxe de la fonctionnalité activée dans un fichier de ferme :
/cache {
/serveStaleOnError "1"
Pour plus de détails, cliquez ici : https://helpx.adobe.com/fr/experience-manager/kb/ServeStaleContentOnError.html
Mise en cache des pages avec des arguments/paramètres de requête
Un des comportements normaux du module du Dispatcher est que si une requête contient un paramètre de requête dans l’URI (généralement affiché comme /content/page.html?myquery=value), elle omettra la mise en cache du fichier et accèdera directement à l’instance AEM. Cette requête est alors considérée comme une page dynamique et ne devrait pas être mise en cache. Cela peut avoir des conséquences sur l’efficacité du cache.
Si des pages dans AEM utilisent des arguments GET ou des paramètres de requête dans la ligne d’adresse pour faciliter le fonctionnement de la page, mais n’effectuent pas le rendu de différentes pages HTML, alors elles sont idéales pour cet élément de configuration.
Vous pouvez indiquer au répartiteur quels arguments ignorer et mettre la page en cache.
Par exemple, quelqu’un a construit un mécanisme de référence des liens profonds pour les médias sociaux qui utilise la référence d’argument dans l’URI afin de savoir d’où vient la personne.
Exemple d’utilisation :
https://www.weretail.com/home.html?reference=android
https://www.weretail.com/home.html?reference=facebook
La page peut être mise en cache à 100 %, mais elle ne l’est pas en raison de la présence des arguments. Pour contourner ce problème, nous ajoutons la section suivante à notre fichier de configuration de la ferme :
/cache {
/ignoreUrlParams {
/0001 { /glob "*" /type "deny" }
/0002 { /glob "reference" /type "allow" }
}
Maintenant, quand le répartiteur verra la requête, il ignorera le fait que la requête a le paramètre de requête ?reference et mettra toujours la page en cache.
Mise en cache des en-têtes de réponse
Il est clair que le répartiteur met en cache les pages.html et les bibliothèques clientes. Mais saviez-vous qu’il peut aussi mettre en cache certains en-têtes de réponse en plus du contenu dans un fichier du même nom mais avec une extension .h ? Ainsi, la prochaine réponse concernera non seulement le contenu, mais aussi les en-têtes de réponse qui lui sont associés, à partir du cache.
AEM ne se limite pas à l’encodage UTF-8 
Parfois, les éléments ont des en-têtes spéciaux qui aident à contrôler les détails d’encodage du délai d’activation du cache, et les derniers horodatages modifiés.
Ces valeurs, lorsqu’elles sont mises en cache, sont supprimées par défaut et le serveur web httpd d’Apache gérera lui-même la ressource avec ses méthodes de traitement de fichiers habituelles, qui se limitent normalement à une estimation de type MIME basée sur les extensions des fichiers.
Si vous disposez du répartiteur, mettez en cache la ressource et les en-têtes souhaités. Vous pouvez faire part des bons résultats obtenus et vous assurer que tous les détails sont transmis au navigateur du client.
Voici un exemple d’une ferme avec les en-têtes à mettre en cache spécifiés :
/cache {
/headers {
"Cache-Control"
"Content-Disposition"
"Content-Type"
"Expires"
"Last-Modified"
"X-Content-Type-Options"
}
}
Dans l’exemple, AEM a été configuré pour afficher les en-têtes. Le réseau de diffusion de contenu cherche à savoir quand invalider son cache. Ce qui veut dire qu’AEM peut maintenant indiquer correctement quels fichiers sont invalidés en fonction des en-têtes.
Gardez à l’esprit que vous ne pouvez pas utiliser d’expressions régulières ou de correspondance de glob. C’est une liste littérale des en-têtes à mettre en cache. Ne placez que la liste des en-têtes littéraux que vous souhaitez mettre en cache.
Période de grâce invalidée automatiquement
Sur les systèmes AEM qui comptent un grand nombre d’activités de la part d’auteurs qui effectuent beaucoup d’activations de pages, vous pouvez disposer d’une condition de concurrence où des invalidations à répétition se produisent. Les requêtes de purge répétitives ne sont pas nécessaires. Vous pouvez prévoir une marge de tolérance pour éviter la répétition d’une purge jusqu’à ce que la période de grâce soit terminée.
Exemple de fonctionnement :
Si vous avez 5 demandes d’invalidation de /content/exampleco/en/, tout se passe dans un délai de 3 secondes.
Avec cette fonction désactivée, vous invalidez 5 fois le répertoire du cache /content/exampleco/en/
Avec cette fonction activée et réglée sur 5 secondes, le répertoire de cache /content/exampleco/en/ est invalidé une fois.
Voici un exemple de syntaxe de cette fonction en cours de configuration pour une période de grâce de 5 secondes :
/cache {
/gracePeriod "5"
Invalidation basée sur le délai d’activation
Une fonctionnalité plus récente du module du répartiteur fut le délai d’activation (TTL) basé sur les options d’invalidation pour les éléments en cache. Lorsqu’un élément est mis en cache, il recherche la présence d’en-têtes de contrôle du cache et génère un fichier dans le répertoire du cache portant le même nom et uneextension .ttl.
Voici un exemple de la fonction en cours de configuration dans le fichier de configuration de la ferme :
/cache {
/enableTTL "1"
AEM doit encore être configuré pour envoyer des en-têtes TTL afin que le répartiteur les respecte. En activant cette fonction, le répartiteur peut seulement savoir quand supprimer les fichiers pour lesquels AEM a envoyé des en-têtes de contrôle du cache. Si AEM ne démarre pas l’envoi des en-têtes TTL, alors le répartiteur ne fera rien de particulier ici.
Règles de filtre du cache
Voici un exemple de configuration de la ligne de base pour laquelle les éléments sont à mettre en cache sur un éditeur :
/cache{
/0000 {
/glob "*"
/type "allow"
}
/0001 {
/glob "/libs/granite/csrf/token.json"
/type "deny"
}
Nous voulons rentabiliser au maximum notre site publié et tout mettre en cache.
Si des éléments perturbent l’expérience lors de la mise en cache, vous pouvez ajouter des règles pour supprimer l’option de mise en cache de cet élément. Comme vous pouvez le constater dans l’exemple ci-dessus, les jetons CSRF ne devraient jamais être mis en cache et ont été exclus. Pour de plus amples informations sur la rédaction de ces règles, cliquez ici.
Accéder à votre compte