Documentation

Comment optimiser le cache de Dispatcher ?

Last update: Tue Jul 16 2024 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. Il décrit également les étapes permettant d’activer les invalidations de style TTL ("Time to Live" ou expiration), de désactiver les agents de purge Dispatcher, de récupérer à nouveau Dispatcher flush, etc.

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 proxy inverse de mise en cache 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 de cet article, le module Dispatcher est pris en charge sur Apache HTTP Server, Microsoft IIS et iPlanet.

Résolution resolution

Comment fonctionne la mise en cache de Dispatcher ?

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 :

  1. Fonctionnement de Dispatcher et procédure d’installation.
  2. Options de configuration disponibles dans Dispatcher.
  3. Webinaire sur le fonctionnement de 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 de Dispatcher, l’utilisation du réseau de diffusion de contenu et la sécurité.
  5. Session Gems sur les nouvelles fonctionnalités de Dispatcher (après v4.1.9).

Optimisation du cache Dispatcher

Voici quelques méthodes pour 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. Cache 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 exploiter Ajax (appels Asynchrones JavaScript 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 pour différentes périodes. du temps.

  3. Ne supprimez jamais le cache Dispatcher sur un Dispatcher actif - Si un Dispatcher diffuse du contenu en direct et que vous supprimez le cache, cela entraîne un flot massif de demandes de retour à AEM.  En conséquence, le cache de Dispatcher ne doit jamais être supprimé sur une Dispatcher active.

  4. Premier du cache : avant de supprimer le cache 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 Dispatcher avant de le placer sur l’équilibreur de charge.

  5. Pages d’erreur du cache - Utilisez la directive DispatcherPassError 1 (spécifique au serveur web Apache) pour diffuser des pages d’erreur telles que 404 du cache de Dispatcher.

  6. GZip compresse tous les types de fichiers sauf 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. Activez /serveStaleOnError dans la configuration /cache - Servez l’ancien fichier cache lorsque les instances AEM diffusent des erreurs.

  8. Ajoutez /gracePeriod à la configuration /cache - Définissez le nombre de secondes pendant lesquelles une ressource obsolète et auto-invalidée 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. Ajoutez 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. Cache-Control and Last-Modified response headers - Utilisez la configuration /headers pour mettre en cache les en-têtes de réponse HTTP Cache-Control et Last-Modified (et/ou l’en-tête 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. Le contenu du cache aussi longtemps que possible et réduisent les requêtes qui reviennent à l’AEM - Optimisez les requêtes de purge en activant le vidage de récupération sur tous les agents de purge. Voir la section ci-dessous intitulée Récupération de Dispatcher Flush. Ou utilisez l’en-tête /enableTTL et définissez 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

À compter de la version 4.1.1 de Dispatcher, /enableTTL 1 peut être défini dans n’importe quelle configuration de fichier.  Ce paramètre permet à Dispatcher de respecter les expirations du cache définies dans l’en-tête de réponse Cache-Control HTTP.  En d’autres termes, Dispatcher fonctionne 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é cela et 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 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 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 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.1.11 ou version ultérieure.
  3. Définissez /enableTTL 1 dans toute configuration de ferme 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 :

Dispatcher utilise désormais l’en-tête Cache-Control pour contrôler l’invalidation des fichiers de cache.  Dans la mesure où cela est le cas, la purge Dispatcher 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. Autorisation des demandes de vidage Dispatcher manuelles 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’émettre des vidages manuels du cache 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 =>   Option 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 de Dispatcher Flush

Pour optimiser les requêtes de vidage Dispatcher, tous les agents de vidage 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 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 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.  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