Présentation

Cet article se concentre sur les dernières optimisations du dispatcher AEM et sur la manière de les exploiter.  Le dispatcher AEM est un serveur proxy inverse de cache conçu pour être utilisé avec Adobe Experience Manager.  Il peut être installé et exécuté en tant que module dans le logiciel de serveur Web existant.  Au moment de l'écriture de cet article, le module dispatcher est pris en charge sur Apache HTTP Server, Microsoft IIS et iPlanet.

Fonctionnement de la mise en cache du dispatcher.

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

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

  1. Fonctionnement du dispatcher et guide d'installation.
  2. Options de configuration disponibles du dispatcher.
  3. Webinaire sur le fonctionnement du dispatcher - Remarque : certaines informations de cette présentation sont basées sur des versions antérieures du dispatcher.
  4. Sessions du webinaire Gems à propos des fonctionnalités du dispatcher, de l'utilisation du réseau de distribution de contenu et de la sécurité.
  5. Session Gems sur les nouvelles fonctionnalités dans le dispatcher (version ultérieure à la v4.1.9).

Optimisation du cache de Dispatcher

Voici quelques méthodes pour optimiser la mémoire 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. Mettez en cache le contenu personnalisé pour différentes périodes - Si votre site dispose de contenu personnalisé, considerez l'utilisation Apache Sling Dynamic Includes > dans l'application AEM pour optimiser les appels Ajax (JavaScript et XML asynchrones au niveau du navigateur), SSI (Server Side Includes au niveau du serveur Web) et ESI (Edge-side Includes au niveau CDN) pour mettre en cache différentes parties de la page pendant différentes périodes.
  3. Ne supprimez jamais le cache du dispatcher sur un dispatcher direct - Si un dispatcher diffuse du contenu en direct et que vous supprimez le cache, cela provoquera un flux massif de demandes de retour à AEM.  Pour cette raison, la mémoire cache du dispatcher ne doit jamais être supprimée sur un dispatcher direct.
  4. Amortissent du cache - Avant de supprimer le cache du dispatcher, retirez-le de votre équilibreur de charge, supprimez le cache, puis exécutez un outil de balayage 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 - Mettez la directive DispatcherPassError 1 (spécifique au serveur web d'Apache) au service de pages d'erreurs telles que les pages 404 depuis le cache du dispatcher.
  6. GZip compresse tous les types de fichier sauf ceux qui sont pré-compressés - Dans le serveur web d'Apache, mod_deflate peut être utilisé, mais assurez-vous que l'en-tête Varier: Utilisateur-Agent n'est pas définie.  Sous Microsoft IIS, utilisez Compression dynamique.
  7. Activez /serveStaleOnError - pour servir l'ancien fichier cache pendant que les instances AEM servent les erreurs.
  8. Ajoutez des règles à /ignoreUrlParams - Ignorez les paramètres de chaîne de requête qui ne sont ni demandés ni 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.
  9. Mise en cache des en-têtes Cache-Control et Last-Modified - Utilisez la configuration des /en-têtes pour la mise en cache des en-têtes de réponse HTTP Cache-Control et Last-Modified (et/ou l'en-tête ETag si vous l'envoyez depuis un AEM).  Cela facilite et optimise la mise en cache au niveau des CDN et du navigateur.  La mise en cache de ces en-têtes permet de définir uniquement les en-têtes par AEM, et non le serveur Web lui-même.  Notez que lorsque vous procédez à cette opération, vous devez commencer à envoyer les en-têtes à partir de votre application AEM.
  10. Mettez en cache le contenu pour aussi longtemps que possible et reduisez les requêtes qui reviennent à AEM - Optimisez les requêtes de vidage en activant rerécupération videz sur tous les agents de vidage.  Utilisez /enableTTL et définissez l'en-tête Cache-Control: max-age=... à mise en cache aussi longtemps que possible.  Consultez ci-dessous pour plus de détails à ce sujet.

Utilisation de délais d'activation

À partir de la version Dispatcher 4.2.3, /enableTTL 1 peut être défini dans le fichier de configuration .any.  Ce paramètre permet au dispatcher de respecter les délais d'expiration de cache définis dans l’en-tête de réponse HTTP Cache-Control.  En d'autres termes, le dispatcher fonctionne de manière similaire à un CDN où la principale forme d’invalidation du cache se produit lorsque les fichiers expirent.  Une fois que vous avez implémenté cela et commencé à envoyer Cache-Control: max-age=... pour toutes les réponses 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 pouvez toujours être amené à vider la mémoire cache du dispatcher.  Dans ce cas, vous pouvez utiliser ACS Commons - Dispatcher Flush UI.  Cet outil est installé sur l’instance d’auteur.  Elle fournit aux utilisateurs une interface utilisateur permettant d’annuler les requêtes de récupération manuelle du cache.

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 l'en-tête Cache-Control et Last-Modified pour toutes les demandes pour lesquelles il n'est pas déjà défini.
  2. Installez Dispatcher 4.2.3 ou version ultérieure.
  3. Définissez /enableTTL 1 dans la configuration de la ferme .any 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ésactiver les agents de vidage du répartiteur sur les instances de publication :

Le dispatcher utilise maintenant 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 requis.

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

III. Autorisez les demandes de purge manuelle du dispatcher provenant de l'instance de l'auteur.

Une fois que les agents de purge sont désactivés, vous pouvez vous reposer entièrement sur l'en-tête Cache-Control pour contrôler quel contenu a été actualisé sur le dispatcher.   Vous pouvez toujours autoriser les utilisateurs à émettre des purges manuelles de la mémoire cache du dispatcher :

  1. Installez ACS Commons - Dispatcher Flush UI sur l'instance d'auteur.
  2. Configurez les agents de purge sur l’instance d’auteur.
  3. Dans chaque configuration d'agent, activez l'option Triggers => Ignore Default. Cette option permet aux agents de purge dans l'IU d'AEM d'ignorer les clics des utilisateurs sur (Un)Publish ou (De)Activate.

Re-fetching Dispatcher Flush

Pour optimiser les demandes d’annulation du dispatcher, tous les agents de vidage du dispatcher doivent disposer d’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 de dispatcher. Par exemple /etc/replication/agents.author/flush.html
  5. Cliquez sur Modifier
  6. Définissez les suivantes :
    • Type de sérialisation = Récupérer le vidage du dispatcher
    • Étendu => Méthode http = POST
  7. Cliquez sur Enregistrer

Notez que le package installé ci-dessus est simplement un exemple de base.  Pour personnaliser et optimiser les récupérations de vidage, vous pouvez modifier la liste des URI qu’elle envoie.  Le code est libre de droits et se trouve ici.  Le code ajoute une liste d’URI au corps de la demande en tant que paramètres indiquant au dispatcher les chemins à récupérer.  Vous pouvez ajouter des chemins supplémentaires en fonction des besoins de votre application pour optimiser les capacités de mise en cache de votre site.

Une explication plus détaillée des récupérations de vidage.

En général, une purge de dispatcher s’effectue en supprimant les fichiers :

  1. Touchez les fichiers .stat
  2. Supprimez /content/foo.*
  3. Supprimez /content/foo/_jcr_content

Étant donné 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é », les demandes 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 de trafic volumineuses, telles que les pages d’accueil, cela peut entraîner une réexécution du niveau d’instance de publication.

Pour résoudre ce problème, activez une fonctionnalité du dispatcher appelée ré-extraction.  Cette fonctionnalité vous permet d'envoyer une liste d’URI que le dispatcher doit « récupérer » de manière proactive et remplacer à la place de supprimer.

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

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne