Comment optimiser le cache de Dispatcher ?

Cet article fournit des instructions détaillées sur les différentes manières d’optimiser le cache de Dispatcher. Il décrit également les étapes permettant d’activer les invalidations de style TTL ("Durée de vie" ou expiration), de désactiver les agents de vidage de Dispatcher, de récupérer à nouveau le vidage de Dispatcher, entre autres.

Description 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. 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 de Dispatcher est pris en charge sur Apache HTTP Server, Microsoft IIS et iPlanet.

Résolution resolution

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 Dispatcher, voir les liens connexes :

Optimisation du cache de Dispatcher

Voici quelques façons d’optimiser le cache de 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 utiliser 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 de diffusion de contenu) 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 actif  - Si un Dispatcher diffuse du contenu en direct et que vous supprimez le cache, cela 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. Blocage du cache  - Avant de supprimer le cache de Dispatcher, retirez-le 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 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 de 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 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 n’importe quelle configuration de fichier.  Ce paramètre rend Dispatcher conforme aux expirations de cache définies dans l’en-tête de réponse HTTP Cache-Control.  En d’autres termes, Dispatcher fonctionnera comme un réseau de diffusion de contenu où la 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 de Dispatcher dans les instances de publication.

Après avoir désactivé les agents de purge sur les instances de publication, vous pouvez toujours purger 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. 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 toute configuration de ferme 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 de Dispatcher sur les instances de publication :

Dispatcher utilise désormais l’en-tête Cache-Control pour contrôler l’invalidation des fichiers de cache.  Comme c’est le cas, la purge de 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. Autoriser les demandes de vidage manuelles 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 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’émettre 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  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 purge de Dispatcher, tous les agents de purge de Dispatcher doivent avoir une fonctionnalité appelée vidage de récupération activée.

Pour activer la récupération à nouveau du vidage du répartiteur, 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 é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 à 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 de 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é de Dispatcher appelée récupération à nouveau.  Cette fonctionnalité vous permet d’envoyer une liste d’URI que Dispatcher doit "récupérer" 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