Documentation

Comment optimiser le cache de Dispatcher ?

Last update: Fri Jun 20 2025 00:00:00 GMT+0000 (Coordinated Universal Time)

Cet article fournit des instructions détaillées sur les différentes manières d’optimiser le cache de Dispatcher. Elle décrit en outre les étapes à suivre pour activer les invalidations de style TTL (« Time to Live » ou expiration), désactiver les agents de vidage Dispatcher, récupérer le vidage Dispatcher, entre autres.

Description description

Environnement

Adobe Experience Manager

Problèmes/Symptômes

Cet article se concentre sur les dernières optimisations d’AEM Dispatcher et sur la manière de les exploiter au mieux. AEM Dispatcher est un serveur de mise en cache proxy inverse 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 module Dispatcher est pris en charge sur le serveur HTTP Apache, Microsoft IIS et iPlanet.

Résolution resolution

Comment fonctionne la mise en cache du Dispatcher ?

Au niveau le plus bas, 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.

Consultez les liens connexes pour plus d’informations sur le Dispatcher :

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

Optimisation du cache de Dispatcher

Voici quelques méthodes d’optimisation du cache de Dispatcher :

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

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

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

  4. Prime du cache - Avant de supprimer le cache de Dispatcher, extrayez le Dispatcher de votre répartition de charge, supprimez le cache, puis exécutez un outil de moteur de recherche Web pour mettre en cache les fichiers sur Dispatcher avant de le placer sur la répartition de charge.

  5. Mettre en cache les pages d’erreur - Tirez parti de la directive DispatcherPassError 1 (spécifique au serveur web Apache) pour traiter les pages d’erreur, telles que les erreurs 404 depuis le cache de Dispatcher.

  6. Compresser au format GZip 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 Vary: User-Agent header n’est pas défini.  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 - traitez l’ancien fichier cache lorsque les instances AEM traitent 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 traité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. Mettre en cache les en-têtes de réponse Cache-Control et Last-Modified - Utilisez la configuration /headers pour mettre en cache les en-têtes de réponse HTTP Cache-Control et Last-Modified (et/ou ETag 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 requêtes qui reviennent à AEM - Optimisez les requêtes de vidage en activant le vidage refetching sur tous les agents de vidage. Consultez la section ci-dessous intitulée Récupérer le vidage du Dispatcher. Ou utilisez /enableTTL et définissez l’en-tête 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 n’importe quelle configuration de fichier.  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 ensuite désactiver en toute sécurité vos agents de vidage Dispatcher dans les instances de publication.

Après avoir désactivé les agents de vidage sur les instances de publication, vous souhaiterez peut-être quand même vider le cache de 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. Modifiez le code source dans l’application AEM pour envoyer Cache-Control header et Last-Modified pour toutes les requêtes pour lesquelles il n’est pas déjà défini.
  2. Installez Dispatcher version 4.1.11 ou ultérieure.
  3. Définissez /enableTTL 1 dans n’importe quelle configuration de batterie du site.
  4. Définissez la configuration /headers pour mettre en cache les en-têtes Cache-Control et Last-Modified.
  5. Redémarrez le serveur web.

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

Le Dispatcher utilise désormais l’en-tête Cache-Control pour contrôler l’invalidation des fichiers 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 de Dispatcher à partir de l’instance d’auteur :

Maintenant que les agents de vidage sont désactivés, vous pouvez vous reposer entièrement sur l’en-tête Cache-Control 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 de 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 option activée. 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 du Dispatcher

Pour optimiser les requêtes de vidage Dispatcher, tous les agents de vidage Dispatcher doivent avoir une fonctionnalité appelée ‘Récupération du vidage 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 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 simplement 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 à 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 Dispatcher fonctionne en supprimant des fichiers :

  1. Touchez les fichiers .stat
  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 comme /content/foo.html ou /content/foo.json, alors que le fichier est « récupéré à nouveau », les requêtes suivantes pour le même fichier sont é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.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f