Comment optimiser le cache de Dispatcher ?

Description

Environnement
Adobe Experience Manager

Problèmes/symptômes
Cet article se concentre sur les dernières optimisations du Dispatcher AEM et sur la manière de les exploiter au mieux. Le Dispatcher AEM est une mise en cache proxy inverse serveur conçu pour être utilisé avec Adobe Experience Manager. Il peut être installé et exécuté en tant que module dans un logiciel de serveur web existant. Au moment de la rédaction du présent article, le Le module dispatcher est pris en charge sur Apache HTTP Server, Microsoft IIS et iPlanet.

Résolution

Comment la mise en cache de Dispatcher fonctionne-t-elle ?

Au niveau le plus élémentaire, le Dispatcher AEM est un proxy inverse qui fonctionne en exécutant la mise en cache, le vidage du cache et l’invalidation du cache.

Pour plus d’informations sur le Dispatcher, voir les liens connexes :

1. Fonctionnement du Dispatcher et procédure d’installation.
2. Options de configuration disponibles dans le Dispatcher.
3. Webinaire sur le fonctionnement du Dispatcher - notez que certaines informations de la présentation sont basées sur les anciennes versions du Dispatcher.
4. Session de webinaire Gems sur les fonctionnalités du Dispatcher, l’utilisation et la sécurité du réseau CDN.
5. Session Gems sur les nouvelles fonctionnalités du Dispatcher (version ultérieure à la version 4.1.9).

Optimisation du cache de Dispatcher

Voici quelques façons d’optimiser le cache du dispatcher :

1. Cache presque tout - Cela signifie mettre en cache tout contenu qui serait demandé plus d’une fois par les utilisateurs.

2. Mise en cache du contenu personnalisé pour différentes périodes - Si votre site comporte du contenu personnalisé, envisagez d’utiliser Inclusions dynamiques Apache Sling dans votre application AEM pour tirer parti des appels Ajax (JavaScript asynchrones et XML au niveau du navigateur), SSI (Server Side Includes au niveau du serveur web) et ESI (Edge-side Includes au niveau du CDN) pour mettre en cache différentes parties de la page pendant différentes périodes.

3. Ne jamais supprimer le cache du Dispatcher sur un Dispatcher dynamique - Si un Dispatcher diffuse du contenu dynamique et que vous supprimez le cache, cela provoquera un flot massif de demandes de retour à AEM.  En conséquence, le cache du Dispatcher ne doit jamais être supprimé sur un Dispatcher dynamique.

4. Blocage du cache - Avant de supprimer le cache du dispatcher, retirez le dispatcher de votre équilibreur de charge, supprimez le cache, puis exécutez un outil de moteur de recherche web pour mettre en cache les fichiers sur le dispatcher avant de le placer sur l’équilibreur de charge.

5. Pages d’erreur de cache - Tirez parti des DispatcherPassError 1 (Spécifique au serveur web Apache) directive permettant de diffuser des pages d’erreur telles que 404 du cache du Dispatcher.

6. GZip compresse tous les types de fichiers à l’exception de ceux qui sont pré-compressés. - Dans le serveur web Apache, mod_deflate peut être utilisé, mais assurez-vous que la variable Vary: User-Agent header n’est pas définie.  Dans Microsoft IIS, utilisez Compression dynamique.

   Exemple de configuration Apache (en spécifiant uniquement certains types de contenu pour éviter les types de fichiers pré-compressés) :

   AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript

7. Activer /serveStaleOnError dans la configuration /cache - Servez l’ancien fichier cache lorsque les instances AEM diffusent des erreurs.

8. Ajouter /gracePeriod à la configuration /cache - Définissez le nombre de secondes pendant lesquelles une ressource obsolète et invalidée automatiquement peut toujours être diffusée à partir du cache après le dernier événement de publication de contenu ("activation").  Cela réduit le nombre de requêtes qui reviennent aux instances de publication lors d’une activité de publication de contenu importante, telle qu’une « Activation d’arborescence ».

9. Ajouter des règles à /ignoreUrlParams - Ignorez les paramètres de chaîne de requête qui ne sont pas requis ou utilisés par l’application.  Cela permet la mise en cache des URL même lorsqu’une chaîne de requête est présente.

10. Mise en cache des en-têtes de réponse Cache-Control et Last-Modified - Utilisez la variable /headers configuration pour mettre en cache les en-têtes de réponse HTTP Cache-Control et Last-Modified (et/ou ETag en-tête si vous l’envoyez à partir d’AEM).  Cela permet de simplifier et d’optimiser la mise en cache au niveau du réseau CDN et du navigateur.  La mise en cache de ces en-têtes permet que seul AEM définisse les en-têtes, et non le serveur web lui-même.  Notez que lorsque vous procédez de la sorte, vous devez commencer à envoyer les en-têtes à partir de votre application AEM.

11. Mettre en cache le contenu aussi longtemps que possible et réduire les demandes qui reviennent à AEM - Optimisez les requêtes de purge en activant la purge de récupération sur tous les agents de purge. Voir la section ci-dessous intitulée Récupération du vidage de Dispatcher. Ou utilisez /enableTTL et défini Cache-Control: max-age=… pour mettre en cache les fichiers aussi longtemps que possible.  Voir ci-dessous pour plus d’informations sur cette rubrique.

Utilisation de TTL

Depuis la version 4.1.11 de Dispatcher, /enableTTL 1 peut être défini dans la configuration de fichier .any .  Ce paramètre permet au dispatcher de respecter les expirations du cache définies dans l’en-tête de réponse HTTP Cache-Control.  En d’autres termes, le Dispatcher fonctionnera comme un réseau CDN où une forme principale d’invalidation du cache se produit lorsque les fichiers expirent.  Une fois que vous avez implémenté ceci et que vous avez commencé à envoyer Cache-Control: max-age=… pour toutes les réponses d’AEM, vous pouvez désactiver en toute sécurité vos agents de vidage du dispatcher dans les instances de publication.

Après avoir désactivé les agents de vidage sur les instances de publication, vous pourriez vouloir vider le cache du Dispatcher.  Dans ce cas, vous pouvez utiliser ACS Commons - Dispatcher Flush UI.  Cet outil est installé sur l’instance de création.  Il fournit aux utilisateurs une interface utilisateur dans laquelle ils peuvent exécuter des requêtes de vidage de cache manuel.

I. Étapes pour activer les invalidations de style TTL (« Time to Live » ou expiration) :

1. Modifier le code source dans l’application AEM à envoyer Cache-Control header et Last-Modified pour toutes les requêtes pour lesquelles elle n’est pas déjà définie.
2. Installez Dispatcher 4.1.11 ou version ultérieure.
3. Définir /enableTTL 1 dans la configuration de la ferme .any du site.
4. Définissez la variable /headers configuration pour mettre en cache la variable Cache-Control et Last-Modified en-têtes.
5. Redémarrez le serveur web.

II. Désactivez les agents de vidage du Dispatcher sur les instances de publication :.

Le Dispatcher utilise désormais l’en-tête Cache-Control pour contrôler l’invalidation des fichiers de cache.  Comme c’est le cas, le vidage du Dispatcher à partir des instances de publication n’est plus nécessaire.

1. Accédez à /etc/replication/agents.publish.html sur chaque instance de publication.
2. Accédez à la configuration de chaque agent de vidage et désactivez l’agent.

III. Autorisez les requêtes de vidage manuel du Dispatcher à partir de l’instance de création :.

Maintenant que les agents de vidage sont désactivés, vous pouvez vous reposer entièrement sur la variable Cache-Control en-tête pour contrôler le moment où le contenu est actualisé sur le Dispatcher.  Vous pouvez toujours permettre aux utilisateurs d’effectuer des vidages manuels du cache du Dispatcher :

1. Installer ACS Commons - Dispatcher Flush UI sur l’instance de création.
2. Configurez les agents de vidage sur l’instance de création.
3. Dans chacune des configurations de l’agent, définissez Triggers =>  Ignorer la valeur par défaut pour activer. Cette option permet aux agents de vidage d’ignorer les utilisateurs qui cliquent sur Publier/Annuler la publication ou Activer/Désactiver dans l’interface utilisateur d’AEM.

Récupération du vidage de Dispatcher

Pour optimiser les requêtes de vidage du répartiteur, tous les agents de vidage du répartiteur doivent avoir une fonctionnalité appelée vidage de récupération activée.

Pour activer la récupération du vidage du Dispatcher, procédez comme suit :

1. Accédez à http://aemhost:port/crx/packmgr/index.jsp et connectez-vous en tant qu’administrateur.
2. Téléchargez le package ici.
3. Téléchargez et installez le package dans le gestionnaire de packages.
4. Accédez à la configuration de l’agent de vidage du Dispatcher. Par exemple /etc/replication/agents.author/flush.html
5. Cliquez sur Modifier.
6. Définissez les éléments suivants :
   • Type de sérialisation = Récupérer le vidage du Dispatcher
   • Étendu =>  Méthode HTTP = POST
7. Cliquez sur Enregistrer.

Remarque : Le package installé ci-dessus est un exemple de base.  Pour personnaliser et optimiser la récupération du vidage, vous pouvez modifier la liste des URI qu’il envoie.  Le code est en open source et se trouve ici.  Le code ajoute une liste d’URI au corps de la requête en tant que paramètres indiquant au Dispatcher les chemins à récupérer.  Vous pouvez ajouter d’autres chemins en fonction des exigences de votre application afin d’optimiser les fonctionnalités de mise en cache de votre site.

Explication détaillée de la récupération du vidage

Normalement, un vidage du dispatcher fonctionne en supprimant des fichiers :

1. Fichier(s) .stat tactile
2. Supprimez /content/foo.*
3. Supprimer /content/foo/_jcr_content

En raison du fait que les fichiers sont supprimés à l’étape 2, la prochaine fois qu’un utilisateur demande un fichier tel que /content/foo.html ou /content/foo.json, alors que le fichier est "récupéré à nouveau", les demandes suivantes pour le même fichier seront également envoyées aux instances de publication jusqu’à ce que le fichier soit mis en cache.  Pour les réponses lentes ou les pages à trafic élevé, telles que les pages d’accueil, cela peut entraîner une inondation du niveau de l’instance de publication.

Pour résoudre ce problème, activez une fonctionnalité du Dispatcher appelée ‘Récupérer à nouveau’.  Cette fonctionnalité vous permet d’envoyer une liste d’URI que le Dispatcher doit « récupérer à nouveau » de manière proactive et remplacer plutôt que de supprimer.

Voir 22:41-27:05 dans cet enregistrement de présentation pour une démonstration de son fonctionnement et de sa configuration.

Ressources Business.Adobe.com