Présentation de la mise en cache des répertoires

Description

Environnement
Adobe Experience Manager

Problème/Symptômes
Ce document explique comment la mise en cache du Dispatcher se produit et comment elle peut être configurée.
Table des matières

Résolution

Mise en cache des répertoires

Nous utilisons les répertoires de cache par défaut suivants dans nos installations de base.

• Auteur

  • /mnt/var/www/author

• Éditeur

  • /mnt/var/www/html

Lorsque chaque requête traverse le Dispatcher, les requêtes suivent les règles configurées pour conserver une version mise en cache localement de la réponse des éléments éligibles.

Remarque :

Nous gardons intentionnellement la charge de travail publiée distincte de celle de l’auteur, car lorsqu’Apache recherche un fichier dans DocumentRoot, il ne sait pas de quelle instance AEM il provient. Ainsi, même si le cache est désactivé dans la ferme de serveurs de création, si DocumentRoot de l’auteur est identique à l’éditeur, il servira les fichiers du cache lorsqu’il est présent. En d’autres termes, vous diffuserez des fichiers d’auteur à partir du cache publié et vous fournirez une expérience de vraiment mauvaise correspondance pour vos visiteurs. Conserver des répertoires DocumentRoot distincts 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 configurer un agent de vidage de réplication pour chaque DocumentRoot que vous configurez, ce qui augmentera la surcharge de vidage avec chaque activation de page. Utilisez l’espace de noms des fichiers et leurs chemins d’accès entièrement mis en cache et évitez plusieurs DocumentRoots pour les sites publiés.

Fichiers de configuration

Dispatcher contrôle ce qui est admissible comme pouvant être mis en cache dans la section /cache de n’importe quel fichier de ferme.
Dans les fermes de configuration de ligne de base AMS, vous trouverez nos inclusions comme illustré ci-dessous :

/cache {
    /rules {
        $include "/etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any"
    }

Lors de la création des règles pour ce qui doit être mis en cache ou non, reportez-vous à la documentation here

Création de mise en cache

Il y a beaucoup d’implémentations que nous avons vues où les gens ne mettent pas en cache le contenu de l’auteur.
Ils passent à côté d’une énorme mise à niveau des performances et de la réactivité à leurs auteurs.

Parlons de la stratégie adoptée lors de la configuration de la ferme de serveurs de création pour qu’elle soit correctement mise en cache.

Voici une section d’auteur/cache de base de notre fichier de ferme d’auteur :

/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 qu'il faut noter ici, c'est que le /docroot est défini sur le répertoire du cache de l’auteur.

Remarque :

Assurez-vous que votre DocumentRoot dans le fichier .vhost de l’auteur correspond au paramètre farms /docroot .

L’instruction d’inclusion des règles de cache inclut le fichier . /etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any qui contient les règles suivantes :

/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 de création, le contenu change tout le temps et volontairement. Vous souhaitez uniquement mettre en cache les éléments qui ne changeront pas fréquemment.
Nous avons des règles pour mettre en cache /libs, car elles font partie de l’installation de base AEM et changeraient jusqu’à ce que vous ayez installé un Service Pack, un Cumulative Fix Pack, une mise à niveau ou un correctif. La mise en cache de ces éléments est très logique et bénéficie de l’expérience de création des utilisateurs finaux qui utilisent le site.

Remarque :

Gardez à l’esprit que ces règles mettent également en cache /apps c’est là que réside le code d’application personnalisé. Si vous développez votre code sur cette instance, il s’avère très déroutant lorsque vous enregistrez votre fichier et que vous ne voyez pas s’il se reflète dans l’interface utilisateur en raison de la diffusion d’une copie mise en cache. L’intention ici est que si vous effectuez un déploiement de votre code dans AEM, il serait également rare et une partie de vos étapes de déploiement devrait être d’effacer le cache de l’auteur. Encore une fois, les avantages sont énormes, ce qui accélère l’exécution de votre code pouvant être mis en cache pour les utilisateurs finaux.

ServeOnStale (AKA Serve on Stale / SOS)

C'est l'un de ces atouts d'une fonctionnalité de Dispatcher. Si l’éditeur est en cours de chargement ou ne répond plus, il génère généralement un code de réponse http 502 ou 503. Si cela se produit et que cette fonctionnalité est activée, le Dispatcher sera invité à continuer à servir tout contenu qui se trouve encore dans le cache comme un effort, même s’il ne s’agit pas d’une nouvelle copie. Il est préférable de servir quelque chose si vous l’avez plutôt que de simplement afficher un message d’erreur qui n’offre aucune fonctionnalité.

Remarque :

Gardez à l’esprit que si le moteur de rendu de l’éditeur a un délai d’expiration du socket ou un message d’erreur 500, cette fonctionnalité ne se déclenche pas. Si AEM est simplement inaccessible, cette fonctionnalité ne fait rien.

Ce paramètre peut être défini sur n’importe quelle ferme, mais son application aux fichiers de fermes publiés n’a de sens que. Voici un exemple de syntaxe de la fonctionnalité activée dans un fichier de ferme :

/cache {
    /serveStaleOnError "1"

Mise en cache de pages avec des arguments/paramètres de requête

Remarque :

L’un des comportements normaux du module de Dispatcher est que si une requête comporte un paramètre de requête dans l’URI (généralement affiché comme /content/page.html).?myquery=value) ignore la mise en cache du fichier et accède directement à l’instance AEM. Cette requête est considérée comme une page dynamique et ne doit pas être mise en cache. Cela peut avoir un effet négatif sur l’efficacité du cache.

Si des pages d’AEM prennent des arguments ou des paramètres de requête de GET dans la ligne d’adresse qui aident la page à fonctionner, mais que le rendu des différents HTMLS n’est pas différent, cela constitue un bon choix pour cet élément de configuration.

Vous pouvez indiquer au dispatcher les arguments à ignorer et à mettre toujours la page en cache.

Par exemple, quelqu’un a créé un mécanisme de référence de lien profond sur les médias sociaux qui utilise la référence d’argument dans l’URI pour savoir d’où provient la personne.

Cas d’utilisation :

https://www.retail.com/home.html?reference=android

https://www.retail.com/home.html?reference=facebook

La page peut être mise en cache à 100 %, mais elle ne le fait pas car les arguments sont présents.
Pour contourner ce problème, nous ajoutons la section suivante à notre fichier de configuration de ferme :

/cache {
    /ignoreUrlParams {
        /0001 { /glob "*" /type "deny" }
        /0002 { /glob "reference" /type "allow" }
    }

Désormais, lorsque Dispatcher voit la requête, il ignore le fait que la requête possède le paramètre de requête de référence et met tout de même la page en cache.

Mise en cache des en-têtes de réponse

Il est assez évident que le dispatcher met en cache des pages .html et des clientlibs, mais saviez-vous qu’il peut également mettre en cache des en-têtes de réponse particuliers avec le contenu d’un fichier portant le même nom mais avec une extension de fichier .h ? Cela permet à la réponse suivante non seulement au contenu, mais aussi aux en-têtes de réponse qui doivent l’accompagner à partir du cache.

AEM peut gérer plus que le codage UTF-8.

Parfois, les éléments comportent des en-têtes spéciaux qui aident à contrôler les détails de codage du délai d’activation du cache et les horodatages de dernière modification.

Ces valeurs, lorsqu’elles sont mises en cache, sont retirées par défaut et le serveur web httpd Apache effectue sa propre tâche de traitement de la ressource avec ses méthodes de gestion de fichiers normales, qui sont normalement limitées à l’hypothèse de type mime en fonction des extensions de fichier.

Si Dispatcher met en cache la ressource et les en-têtes souhaités, vous pouvez exposer l’expérience appropriée et vous assurer que tous les détails s’affichent dans le navigateur du client.

Voici un exemple de ferme de serveurs 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, ils ont configuré AEM pour diffuser des en-têtes que le réseau de diffusion de contenu recherche pour savoir quand invalider son cache. En d’autres termes, AEM peut désormais dicter correctement les fichiers qui sont invalidés en fonction des en-têtes.

Remarque :

Gardez à l’esprit que vous ne pouvez pas utiliser d’expressions régulières ou de correspondance glob. C'est une liste littérale des en-têtes à mettre en cache. Placez uniquement dans une liste des en-têtes littéraux que vous souhaitez qu’il mette en cache.

Invalidation automatique de la période de grâce

Sur les systèmes d’AEM qui ont une activité importante de la part des auteurs qui effectuent de nombreuses activations de page, vous pouvez avoir une condition de concurrence où des invalidations répétées se produisent. Les demandes de vidage très répétées sont inutiles et vous pouvez créer une certaine tolérance pour ne pas répéter une vidage tant que la période de grâce n’a pas été effacée.

Exemple de fonctionnement :

Si vous avez cinq demandes d’invalidation de /content/exampleco/en/, toutes se produisent dans un délai de 3 secondes.

Avec cette fonction désactivée, vous invalideriez 5 fois le répertoire de cache /content/exampleco/en/ .

Lorsque cette fonction est activée et définie sur 5 secondes, elle invaliderait le répertoire de cache /content/exampleco/en/once.

Voici un exemple de syntaxe de cette fonctionnalité configurée pour une période de grâce de 5 secondes :

/cache {
    /gracePeriod "5"

Invalidation basée sur TTL

Une nouvelle fonctionnalité du module de Dispatcher a été Durée de vie (TTL) options d’invalidation basées sur les éléments mis 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 une .ttl extension .

Voici un exemple de la fonctionnalité configurée dans le fichier de configuration de la ferme :

/cache {
    /enableTTL "1"

Remarque :

Gardez à l’esprit que AEM doit toujours être configuré pour envoyer des en-têtes TTL pour que Dispatcher les honore. Si vous activez cette fonction, le Dispatcher peut uniquement savoir quand supprimer les fichiers pour lesquels AEM a envoyé des en-têtes de contrôle du cache. Si AEM ne commence pas à envoyer des en-têtes TTL, le Dispatcher ne fera rien de spécial ici.

Règles de filtrage du cache

Voici un exemple de configuration de base pour laquelle les éléments à mettre en cache sur un éditeur :

/cache{
    /0000 {
        /glob "*"
        /type "allow"
    }
    /0001 {
        /glob "/libs/granite/csrf/token.json"
        /type "deny"
    }

Nous voulons rendre notre site publié aussi gourmand que possible et tout mettre en cache.

S’il existe des éléments qui rompent l’expérience lorsqu’ils sont mis en cache, vous pouvez ajouter des règles pour supprimer l’option de mise en cache de cet élément. Comme vous pouvez le voir dans l’exemple ci-dessus, les jetons csrf ne doivent jamais être mis en cache et ont été exclus. Vous trouverez plus de détails sur la rédaction de ces règles. here.