La mise en cache est un facteur de performance clé et une source de problèmes lorsqu’elle n’est pas configurée correctement. Cet article donnera un aperçu et des détails pratiques utiles sur la façon d’ajuster la mise en cache pour un environnement de développement local et l’emplacement de stockage des fichiers mis en cache.
Alors, qu’est-ce que le cache dans AEM, et comment fonctionne-t-il ?
Le cache dans AEM est un composant qui stocke de manière transparente les données afin que les futures requêtes pour ces données puissent être servies plus rapidement. Une fois demandé, un document cacheable est vérifié par le Dispatcher pour identifier si ce document existe dans le système de fichiers du serveur web :
- Si le document est mis en cache, le Dispatcher renvoie le fichier.
- Le Dispatcher demande le document à l’instance AEM s’il n’est pas mis en cache.
Par défaut, les ressources ne seront mises en cache que si toutes les conditions suivantes sont remplies :
- La requête HTTP utilise la méthode GET ;
- L’URL demandée a une extension (telle que .html ou .xml) ;
- L’URL demandée n’a pas de chaîne de requête (il n’y a pas de paramètres après l’extension) ;
- La requête n’a pas d’en-tête “Authorization” (sauf si AllowAuthorized est égal à 1).
Les paramètres sont définis dans le fichier de configuration du répartiteur. Dans notre cas, il s’agit d’un fichier conf/dispatcher.any. Le fichier de configuration contient une série de propriétés à valeur unique ou multiple qui contrôlent le comportement du répartiteur :
- les noms de propriétés sont précédés d’une barre oblique (“/”) ;
- les propriétés à valeurs multiples encadrent les éléments enfants à l’aide d’accolades (“{}”) ;
- les commentaires commencent par le symbole ‘#’.
Renders
Premièrement, vous devez spécifier les renders pour le répartiteur. Les renders sont des instances AEM à partir desquelles le répartiteur reçoit le contenu, lequel peut être mis en cache. Les renders sont la première chose que nous définirons dans notre fichier de configuration. Le Dispatcher équilibrera automatiquement la charge entre ces instances AEM si vous définissez plus d’un render. Dans notre cas, nous ne définirons qu’un seul render : l’instance AEM publique.
/renders
{
/rend01
{
/hostname "localhost"
/port "4503"
}
}
Vous pouvez maintenant redémarrer le httpd server et vérifier si le dispatcher peut demander des ressources à une instance AEM publique.
Par exemple, si vous avez une page fonctionnelle http://localhost:4503/content/geometrixx/en.html, alors la version dispatcher de cette page devrait être disponible à l’adresse http://localhost/content/geometrixx/en.html. Notez que nous ne définissons pas le port dans la requête URL car le dispatcher (plus précisément, httpd) fonctionne sur le port 80, qui est la valeur par défaut pour tous les navigateurs.
Filtres
La section /filter spécifie les requêtes HTTP que le dispatcher peut accepter. Toutes les autres requêtes sont renvoyées au serveur web avec un code d’erreur 404 (page non trouvée). Pour notre démonstration, autorisons l’accès à toutes les ressources.
/filter
{
/0001 { /type "allow" /glob "*" }
}
Types de filtres : « autoriser » ou « refuser ».
Les globs seront comparés à la ligne de requête entière, par ex. :
/0001 { /type "allow" /glob "* /index.html *" }
Ce glob correspond à la requête « GET /index.html HTTP/1.1 » mais pas à « GET /index.html?a=b HTTP/1.1 ».
Au lieu des « globs », vous pouvez utiliser des éléments séparés comme « url », « method », « protocol », « extension » pour définir votre filtre. En plus de « url », vous pouvez utiliser « path », « selectors », « extension », « suffix ».
Lorsqu’une requête correspond à plusieurs modèles de filtre, seul le dernier modèle de filtre est appliqué.
Après avoir défini vos filtres, vous pouvez redémarrer httpd et vérifier si le dispatcher a accès à toutes les ressources de l’instance AEM publique. Bien sûr, vous devriez refuser l’accès à certaines ressources pour des raisons de sécurité dans un environnement de production réel.
Cache
La section de mise en cache détermine les ressources que le dispatcher mettra en cache. Cette section contient de nombreuses règles similaires aux règles de filtrage, avec quelques paramètres supplémentaires.
Par exemple, /docroot détermine l’emplacement du répertoire où les fichiers mis en cache sont stockés. La valeur doit être exactement le même chemin que la racine des documents du serveur web afin que le dispatcher et le serveur web puissent gérer les mêmes fichiers.
Pour notre démonstration, configurons le docroot et autorisons la mise en cache de toutes les ressources reçues de notre rendu (instance de publication) :
/cache
{
/docroot "/Apache22/htdocs"
/rules
{
/0000
{
/glob "*"
/type "allow"
}
}
}
Une fois ces modifications appliquées, vous pouvez redémarrer le serveur HTTPd, ouvrir une nouvelle fenêtre de navigation privée pour un accès non autorisé sans utiliser l’en-tête « Authorization » (Chrome ctrl+shift+n, Firefox ctrl+shift+p) et vous rendre sur : http://localhost/content/geometrixx/en/products.html.
Les ressources mises en cache devraient apparaître dans le répertoire htdocs. Les ressources ont une hiérarchie de type URL : les répertoires forment des chemins, et les fichiers HTML statiques contiennent le contenu rendu.
En-têtes
Vous savez que les fichiers HTML mis en cache contiennent uniquement du contenu HTML. Mais que faire si nous voulons mettre en cache les en-têtes de réponse reçus des rendus ?
Par exemple, si les réponses des rendus contiennent un en-tête « Content-Type » qui définit l’encodage, le contenu HTML risque de ne pas s’afficher correctement sans cet en-tête. C’est à cela que sert le bloc /headers situé dans les sections /cache. Mettons en cache certains en-têtes courants et utiles :
/cache
{
/headers
{
"Cache-Control"
"Content-Disposition"
"Content-Type"
"Expires"
"Last-Modified"
"X-Content-Type-Options"
}
}
Après avoir modifié les en-têtes dans votre fichier de configuration du dispatcher, supprimez tout le cache du répertoire htdocs et redémarrez httpd. Ensuite, vous pourrez ouvrir http://localhost/content/geometrixx/en/products.html.
Enfin, vous trouverez non seulement le fichier HTML mis en cache products.html dans le répertoire htdocs/content/geometrixx/en, mais aussi le fichier products.html.h à côté du fichier HTML original products.html. Ce fichier *.h contient les en-têtes pour le fichier HTML mis en cache.
Résumé
Vous pouvez rapidement activer la mise en cache en utilisant les paramètres initiaux suivants dans le fichier de configuration du dispatcher :
- définir les rendus ;
- définir les filtres ;
- définir le htdocs et les règles pour les sections de mise en cache ;
- définir les en-têtes pour le stockage des en-têtes HTTP.
FAQ
Comment fonctionne le cache du dispatcher AEM ?
Une fois demandé, un document cacheable est vérifié par le Dispatcher pour identifier si ce document existe dans le système de fichiers du serveur web :
Si le document est mis en cache, le Dispatcher renvoie le fichier. Le Dispatcher demande le document à l’instance AEM s’il n’est pas mis en cache.
Qu’est-ce que le cache dans AEM ?
Le cache dans AEM est un composant qui stocke les données de manière transparente afin que les futures requêtes pour ces données puissent être servies plus rapidement.
Qu’est-ce que la mise en cache sensible aux permissions dans AEM ?
Le cache sensible aux permissions d’AEM vous permet de mettre en cache des pages sécurisées. Le dispatcher vérifie les autorisations d’accès de l’utilisateur pour une page avant de livrer la page mise en cache.
