Présentation de la mise en cache

Table des matières

<- Précédent : Explication des fichiers de configuration

Ce document explique comment se déroule la mise en cache de Dispatcher et comment elle peut être configurée.

Mise en cache des répertoires

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

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

Fichiers de configuration

Dispatcher contrôle les éléments qualifiés pour la mise en cache dans la section /cache { de tout fichier de batterie.
Dans les batteries de configuration de référence 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 ici.

Mise en cache de l’instance de création

Nous avons vu beaucoup d’applications dans lesquelles le contenu de l’instance de création n’est pas mis en cache.
Les performances s’en trouvent largement dégradées, tout comme la réactivité des auteurs et des autrices.

Parlons de la stratégie utilisée pour configurer notre batterie de serveurs de création pour qu’elle soit correctement mise en cache.

Voici une section d’instance de création de base /cache { de notre fichier de batterie d’instance de création :

/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"
    }
}

Notons ici que la /docroot est définie sur le répertoire du cache de l’instance de création.

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 en permanence et volontairement. Mieux vaut mettre en cache les éléments qui ne changeront pas fréquemment.
Nous avons des règles pour mettre les /libs en cache car elles font partie de l’installation de base d’AEM et changent jusqu’à ce que vous ayez installé un pack de services, un pack de correctifs cumulatifs, une mise à niveau ou un correctif. La mise en cache de ces éléments a donc un sens et bénéficie énormément de l’expérience de création des personnes qui utilisent le site.

ServeOnStale (ou Serve on Stale/SOS)

C’est l’une des merveilleuses fonctionnalités du 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 fonction est activée, le Dispatcher est invité à continuer à servir le contenu qui se trouve encore dans le cache, même s’il ne s’agit pas d’une nouvelle copie. Il est préférable de diffuser quelque chose si vous l’avez plutôt que de simplement afficher un message d’erreur qui n’offre aucune fonctionnalité.

Ce paramètre peut être défini dans n’importe quelle batterie, mais il est logique de l’appliquer uniquement aux fichiers de batterie de publication. Voici un exemple de syntaxe de la fonctionnalité activée dans un fichier de batterie :

/cache {
    /serveStaleOnError "1"

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

Consultez cet article pour connaître l’impact des paramètres de requête importants sur les performances de votre site.

Par défaut, il faut définir les règles ignoreUrlParams pour autoriser *. Cela signifie que tous les paramètres de requête sont ignorés et permettent à toutes les pages d’être mises en cache, quels que soient les paramètres utilisés.

Voici un exemple où une personne 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.

Exemple ignorable :

La page peut être mise en cache à 100 %, mais elle ne le fait pas car les arguments sont présents.
Configurer votre ignoreUrlParams en tant que liste autorisée vous aidera à résoudre ce problème :

/cache {
    /ignoreUrlParams {
        /0001 { /glob "*" /type "allow" }
    }

Désormais, lorsque Dispatcher voit la demande, il ignore le fait que la demande a le paramètre query de la référence ? et met toujours la page en cache.

Exemple dynamique :

Gardez à l’esprit que si vous disposez de paramètres de requête qui modifient le rendu de sortie d’une page, vous devez alors les exclure de la liste ignorée et empêcher la page d’être mise en cache à nouveau. Par exemple, une page de recherche qui utilise un paramètre de requête modifie le code HTML brut rendu.

Voici donc la source HTML de chaque recherche :

/search.html?q=fruit :

<html>
...SNIP...
    <div id='results'>
        <div class='result'>
            Orange
        </div>
        <div class='result'>
            Apple
        </div>
        <div class='result'>
            Strawberry
        </div>
    </div>
</html>

/search.html?q=vegetables :

<html>
...SNIP...
    <div id='results'>
        <div class='result'>
            Carrot
        </div>
        <div class='result'>
            Cucumber
        </div>
        <div class='result'>
            Celery
        </div>
    </div>
</html>

Si vous avez d’abord consulté /search.html?q=fruit, il mettrait en cache le code html avec les résultats qui montrent des fruits.

Ensuite, vous consultez /search.html?q=vegetables en deuxième, mais vous obtenez les résultats de fruits.
En effet, le paramètre de requête de q est ignoré en ce qui concerne la mise en cache. Pour éviter ce problème, vous devez prendre note des pages qui effectuent le rendu de codes HTML différents en fonction des paramètres de requête et qui refusent la mise en cache de ces derniers.

Exemple :

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

Les pages qui utilisent des paramètres de requête via JavaScript continueront à fonctionner entièrement en ignorant les paramètres de cette configuration. Parce qu’ils ne modifient pas le fichier HTML au repos. Ils utilisent JavaScript pour mettre à jour les navigateurs en temps réel sur le navigateur local. En d’autres termes, si vous utilisez les paramètres de requête avec JavaScript, il est très probable que vous puissiez ignorer ce paramètre pour la mise en cache des pages. Autorisez cette page à être mise en cache et profitez à nouveau des performances.

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

Il est assez évident que Dispatcher met en cache les pages .html et les clientlibs (c’est-à-dire .js et .css), mais saviez-vous qu’il peut également mettre en cache des en-têtes de réponse spécifiques le long du contenu dans un fichier portant le même nom, mais avec une extension de fichier .h. Cela autorise l’accès de la prochaine réponse non seulement au contenu, mais aussi aux en-têtes de réponse qui doivent l’accompagner depuis le cache.

AEM peut gérer bien 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 TTL du cache et les horodatages de dernière modification.

Lorsqu’elles sont mises en cache, ces valeurs sont supprimées par défaut et le serveur web Apache httpd s’acquitte de sa propre tâche de traitement de la ressource avec ses méthodes de gestion de fichiers normales, qui sont normalement limitées aux suppositions de type MIME basées sur les extensions de fichier.

Si le 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 atteignent le navigateur des clientes et clients.

Voici un exemple de batterie 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 CDN recherche pour savoir quand invalider son cache. En d’autres termes, AEM peut désormais indiquer correctement les fichiers qui sont invalidés en fonction des en-têtes.

Invalider automatiquement le délai de grâce

Sur les systèmes AEM qui ont une activité importante de la part des créateurs et créatices qui effectuent de nombreuses activations de page, vous pouvez avoir une condition de concurrence où des invalidations répétées se produisent. Les requêtes de purge répétées ne sont pas nécessaires et vous pouvez créer une certaine tolérance pour ne pas répéter une purge tant que le délai de grâce n’a pas été effacé.

Exemple de fonctionnement :

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

Si cette fonction est désactivée, vous invalidez le répertoire du cache /content/exampleco/en/ 5 fois.

Si cette fonction est activée et définie sur 5 secondes, elle invalide le répertoire du cache /content/exampleco/en/ une fois.

Voici un exemple de syntaxe de cette fonctionnalité configurée pour un délai de grâce de 5 secondes :

/cache {
    /gracePeriod "5"

Invalidation basée sur TTL

Le module Dispatcher possède de nouvelles fonctionnalités, les options d’invalidation basée sur Time To Live (TTL) 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 extension .ttl.

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

/cache {
    /enableTTL "1"

Règles de filtrage du cache

Voici un exemple de configuration de base pour les éléments à mettre en cache sur une instance de publication :

/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.

Si des éléments rompent 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 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 ici.

Suivant -> Utiliser et comprendre les variables