Présentation de Dispatcher

Dispatcher est l’outil de mise en cache et/ou d’équilibrage de charge d’Adobe Experience Manager, qui peut être utilisé conjointement avec un serveur web de niveau élevé.

Le processus de déploiement de Dispatcher est indépendant du serveur web et de la plateforme du système d’exploitation choisie :

1. En savoir plus sur Dispatcher (cette page). En outre, voir les questions fréquentes sur Dispatcher.
2. Installez un serveur web pris en charge selon la documentation du serveur web.
3. Installez le module Dispatcher sur votre serveur web et configurez-le en conséquence.
4. Configurez Dispatcher (fichier dispatcher.any).
5. Configurez AEM pour que les mises à jour de contenu invalident le cache.

Utilisez les informations suivantes, selon vos besoins :

• Liste de contrôle de sécurité de Dispatcher
• Base de connaissances de Dispatcher
• Optimisation d’un site web pour les performances du cache
• Utilisation de Dispatcher avec plusieurs domaines
• Utilisation du protocole SSL avec Dispatcher
• Mise en œuvre de la mise en cache sensible aux autorisations
• Résolution des problèmes liés à Dispatcher
• FAQ sur les problèmes fréquents de Dispatcher

Pourquoi utiliser Dispatcher pour mettre en œuvre la mise en cache ?

Il existe deux approches possibles pour la publication web :

• Serveurs web statiques : par exemple Apache ou IIS. Ils sont très simples, mais rapides.
• Serveurs de gestion de contenu : ils fournissent du contenu dynamique et intelligent en temps réel, mais nécessitent davantage de temps de calcul et d’autres ressources.

Dispatcher contribue à la mise en place d’un environnement à la fois rapide et dynamique. Il fonctionne comme un composant d’un serveur HTML statique, par exemple Apache, dans le but :

• de stocker (ou « mettre en cache ») la plus grande partie du contenu du site possible, sous la forme d’un site web statique ;
• de limiter l’accès au moteur de mise en page.

Cela signifie que :

• le contenu statique est géré avec la même rapidité et la même facilité que sur un serveur web statique, mais vous pouvez également utiliser les outils d’administration et de sécurité disponibles pour vos serveurs web statiques.

• le contenu dynamique est généré en fonction des besoins, sans ralentir le système plus que nécessaire.

Dispatcher contient des mécanismes permettant de générer et de mettre à jour du code HTML statique en fonction du contenu du site dynamique. Vous pouvez spécifier en détail les documents qui sont stockés sous forme de fichiers statiques et ceux qui sont systématiquement générés de façon dynamique.

Cette section illustre les principes de cet environnement.

Serveur web statique

Un serveur web statique, par exemple Apache ou IIS, diffuse les fichiers HTML statiques aux visiteurs du site web. Les pages statiques sont créées une seule fois, de sorte que le même contenu est fourni pour chaque demande.

Ce processus est très simple et, de ce fait, très efficace. Si un visiteur demande un fichier (par exemple une page HTML), il est généralement extrait directement de la mémoire. Sinon, il est lu depuis le disque local. Les serveurs web statiques existent depuis longtemps. De ce fait, il existe une grande variété d’outils pour l’administration et la gestion de la sécurité, et ils sont parfaitement intégrés aux infrastructures réseau.

Serveurs de gestion de contenu

Si vous utilisez un serveur de gestion de contenu, par exemple AEM, un moteur de mise en page avancé traite la demande d’un visiteur. Le moteur lit le contenu à partir d’un référentiel qui, associé à des styles, formats et droits d’accès, transforme le contenu en un document qui est adapté aux besoins et droits du visiteur.

Vous pouvez ainsi créer un contenu plus évolué, dynamique, qui améliore la souplesse et la fonctionnalité du site web. Toutefois, le moteur de mise en page nécessite davantage de puissance de traitement qu’un serveur statique, de sorte que cette configuration peut être sujette à un ralentissement si de nombreux visiteurs utilisent le système.

Procédure de mise en cache par Dispatcher

Répertoire du cache Pour la mise en cache, le module Dispatcher utilise la capacité du serveur web à fournir du contenu statique. Dispatcher place les documents mis en cache à la racine du document du serveur web.

Méthodes de mise en cache

Dispatcher dispose de deux méthodes principales pour mettre à jour le contenu du cache lorsque des modifications sont apportées au site web.

• Les mises à jour de contenu suppriment les pages qui ont été modifiées, ainsi que les fichiers qui leur sont directement associés.
• L’invalidation automatique invalide automatiquement les parties du cache susceptibles d’être obsolètes après une mise à jour. L’invalidation automatique marque les pages correspondantes comme étant obsolètes, sans rien supprimer.

Mises à jour du contenu

Lors d’une mise à jour du contenu, un ou plusieurs documents AEM sont modifiés. AEM envoie une demande de syndication à Dispatcher, qui met à jour le cache en conséquence :

1. Cela supprime les fichiers modifiés du cache.
2. Cela supprime tous les fichiers commençant par le même descripteur du cache. Par exemple, si le fichier /fr/index.html est mis à jour, tous les fichiers qui commencent par /fr/index sont supprimés. Ce mécanisme permet de concevoir des sites dont la mise en cache est performante, en particulier en termes de navigation dans des images.
3. Cela modifie le fichier dont l’extension est stat, ce qui met à jour son horodatage afin d’indiquer la date de la dernière modification.

Notez ce qui suit :

• Les mises à jour du contenu sont habituellement employées en même temps qu’un système de création qui « sait » ce qui doit être remplacé.
• Les fichiers qui sont affectés par une mise à jour du contenu sont supprimés, mais pas remplacés immédiatement. La prochaine fois qu’un tel fichier est demandé, Dispatcher récupère le nouveau fichier auprès de l’instance AEM et le place dans le cache, écrasant ainsi le contenu obsolète.
• En règle générale, les images générées automatiquement avec le texte d’une page sont stockées dans des fichiers images commençant par le même descripteur, garantissant ainsi que l’association existe pour la suppression. Vous pouvez, par exemple, stocker le texte du titre de la page mapage.html en tant qu’image mapage.titreImage.gif dans le même dossier. Ainsi, l’image est automatiquement supprimée du cache chaque fois que la page est mise à jour. Vous êtes ainsi certain que l’image reflète toujours la version actuelle de la page.
• Vous pouvez disposer de plusieurs fichiers stat, par exemple un par dossier de langue. Si une page est mise à jour, AEM recherche le dossier parent suivant contenant un fichier stat, puis modifie ce fichier.

Invalidation automatique

L’invalidation automatique invalide automatiquement des parties du cache, sans supprimer physiquement aucun fichier. À chaque mise à jour du contenu, le fichier stat est modifié afin que son horodatage indique la dernière mise à jour du contenu.

Dispatcher comprend une liste de fichiers qui sont soumis à l’invalidation automatique. Lorsqu’un document de cette liste est demandé, Dispatcher compare la date du document mis en cache à l’horodatage du fichier stat :

• si le document mis en cache est plus récent, Dispatcher le renvoie ;
• s’il est plus ancien, Dispatcher récupère la version actuelle dans l’instance AEM.

Notez également ce qui suit :

• L’invalidation automatique est généralement utilisée lorsque les interdépendances sont complexes, par exemple pour les pages HTML. Ces pages contiennent des liens et des entrées de navigation. Par conséquent, elles doivent généralement être mises à jour après une mise à jour du contenu. Si vous avez automatiquement généré des fichiers PDF ou image, vous pouvez également choisir de les invalider automatiquement.
• L’invalidation automatique n’inclut aucune action de la part de Dispatcher au moment de la mise à jour, hormis la modification du fichier stat. Toutefois, la modification automatique du fichier stat rend le contenu du cache obsolète, sans le supprimer physiquement du cache.

Procédure de renvoi des documents par Dispatcher

Déterminer si le document est soumis à la mise en cache

Vous pouvez définir les documents mis en cache par Dispatcher dans le fichier de configuration ;. Dispatcher vérifie la demande au niveau de la liste des documents pouvant être mis en cache. Si le document ne figure pas dans cette liste, Dispatcher demande le document à l’instance AEM.

Dispatcher demande toujours le document directement à partir de l’instance AEM dans les cas suivants :

• Si l’URI de demande contient un point d’interrogation « ? ». Cela indique généralement une page dynamique, par exemple un résultat de recherche, qui n’a pas besoin d’être mis en cache.
• L’extension de fichier est manquante. Le serveur web a besoin de l’extension pour déterminer le type de document (type MIME).
• L’en-tête d’authentification est défini (vous pouvez le configurer).

Déterminer si un document est mis en cache

Dispatcher stocke les fichiers mis en cache sur le serveur web comme s’ils faisaient partie d’un site web statique. Si l’utilisateur demande un document pouvant être mis en cache, Dispatcher vérifie si le document existe dans le système de fichiers du serveur web :

• si le document est mis en cache, Dispatcher renvoie le fichier ;
• s’il n’est pas mis en cache, Dispatcher demande le document à l’instance AEM.

Déterminer si le document est à jour

Dispatcher vérifie si un document est à jour en deux étapes :

1. Il vérifie si le document est soumis à l’invalidation automatique. Si ce n’est pas le cas, le document est considéré comme étant à jour.
2. Si le document est configuré pour l’invalidation automatique, Dispatcher vérifie s’il est plus ancien ou plus récent que la dernière modification disponible. S’il est plus ancien, Dispatcher demande la version actuelle à l’instance AEM et remplace la version dans le cache.

Les avantages de l’équilibrage de charge

L’équilibrage de charge consiste à distribuer la charge de calcul du site web sur plusieurs instances d’AEM.

Vous bénéficiez des avantages suivants :

• Puissance de traitement accrue En pratique, cela signifie que Dispatcher partage des demandes de document entre plusieurs instances d’AEM. Chaque instance ayant désormais moins de documents à traiter, les délais de réponse sont plus rapides. Dispatcher conserve les statistiques internes pour chaque catégorie de document afin qu’il puisse estimer la charge et distribuer les requêtes efficacement.

• Couverture de sécurité intégrée accrue Si Dispatcher ne reçoit aucune réponse de la part d’une instance, il transmet automatiquement les demandes à l’une des autres instances. Par conséquent, si une instance n’est plus disponible, le seul effet est un ralentissement du site, proportionnel à la puissance de calcul perdue. Toutefois, tous les services continuent de fonctionner.

• Vous pouvez également gérer plusieurs sites web dans le même serveur web statique.

Exécution de l’équilibrage de charge par Dispatcher

Statistiques de performances

Dispatcher conserve les statistiques internes sur la vitesse à laquelle chacune des instances d’AEM traite les documents. En fonction de ces données, Dispatcher estime l’instance qui fournit le temps de réponse le plus rapide lors de la réponse à une demande afin de réserver le temps nécessaire de calcul sur cette instance.

Les différents types de demande peuvent avoir des temps d’exécution moyens différents. De ce fait, Dispatcher permet de spécifier les catégories de document. Elles sont ensuite prises en compte lors du calcul des estimations de durée. Par exemple, vous pouvez effectuer une distinction entre les pages HTML et les images, car leurs délais de réponse types peuvent également varier.

Si vous utilisez une fonction de recherche élaborée, vous pouvez créer une catégorie pour les requêtes de recherche. Cela permet à Dispatcher d’envoyer des requêtes de recherche à l’instance qui répond le plus rapidement. Cela empêche une instance plus lente de créer un blocage lorsqu’elle reçoit plusieurs requêtes de recherche « coûteuses », alors que les autres reçoivent des requêtes « moins coûteuses ».

Contenu personnalisé (connexions persistantes)

Les connexions persistantes garantissent que les documents d’un utilisateur sont tous composés sur la même instance d’AEM. Ceci est important si vous utilisez des pages personnalisées et des données de session. Les données sont stockées sur l’instance. De ce fait, les demandes ultérieures du même utilisateur doivent retourner à cette instance, sinon les données sont perdues.

Les connexions persistantes limitent la capacité de Dispatcher à optimiser les demandes. Vous devez les utiliser uniquement en cas de besoin. Vous pouvez spécifier le dossier qui contient les documents « persistants », assurant ainsi que tous les documents de ce dossier sont composés sur la même instance pour chaque utilisateur.

Utilisation de plusieurs instances de Dispatcher

Avec des configurations complexes, vous pouvez utiliser plusieurs instances de Dispatcher. Par exemple, vous pouvez utiliser :

• une instance de Dispatcher pour publier un site web sur l’intranet ;
• une seconde instance, à une autre adresse et avec d’autres paramètres de sécurité, pour publier le même contenu sur Internet.

Dans ce cas, veillez à ce que chaque demande passe par une seule instance de Dispatcher. Une instance de Dispatcher ne traite pas les demandes provenant d’une autre instance. Par conséquent, assurez-vous que les deux instances de Dispatcher accèdent directement au site web AEM.

Utilisation de Dispatcher avec un CDN

Un réseau de distribution de contenu (CDN), par exemple Akamai Edge Delivery ou Amazon Cloud Front, distribue du contenu à partir d’un emplacement proche de l’utilisateur final. Ainsi, il :

• accélère les temps de réponse pour les utilisateurs finaux ;
• soulage vos serveurs ;

En tant que composant d’infrastructure HTTP, un CDN fonctionne comme une instance de Dispatcher : lorsqu’un nœud CDN reçoit une demande, il diffuse la demande depuis son cache, si possible (la ressource est valide et disponible dans le cache). Autrement, il contacte le serveur suivant le plus proche pour récupérer la ressource et la mettre en cache pour d’autres demandes, le cas échéant.

Le « serveur suivant le plus proche » dépend de votre configuration spécifique. Par exemple, dans une installation Akamai, la requête peut prendre le chemin suivant :

• Le nœud Akamai Edge
• Le calque Akamai Midgres
• Votre pare-feu
• Votre équilibreur de charge
• Dispatcher
• AEM

Dans la plupart des cas, Dispatcher est le serveur suivant qui peut diffuser le document depuis un cache et influencer les en-têtes de réponse renvoyés au serveur CDN.

Contrôle d’un cache CDN

Il existe plusieurs méthodes de contrôle de la durée pendant laquelle un CDN met en cache une ressource avant qu’elle ne soit récupérée auprès de Dispatcher.

1. Configuration explicite
   Configurez la durée pendant laquelle des ressources particulières sont conservées dans le cache du CDN, en fonction du type mime, de l’extension, du type de requête, etc.

2. En-têtes d’expiration et de contrôle du cache
   La plupart des CDN honoreront les en-têtes HTTP Expires: et Cache-Control: s’ils sont envoyés par le serveur en amont. Pour cela, il faut par exemple utiliser le module Apache mod_expires.

3. Invalidation manuelle
   Les CDN permettent de supprimer des ressources du cache via des interfaces web.

4. Invalidation basée sur l’API
   La plupart des CDN offrent également une API REST et/ou SOAP qui permet de supprimer des ressources du cache.

Dans une configuration standard d’AEM, la configuration par extension et/ou chemin d’accès, qui peut être obtenue en suivant les points 1 et 2 ci-dessus, offre des possibilités pour définir des périodes de mise en cache raisonnables pour les ressources utilisées fréquemment qui ne changent pas souvent, comme les images de conception et les bibliothèques client. Lorsque de nouvelles versions sont déployées, une invalidation manuelle est généralement nécessaire.

Si cette approche est utilisée pour mettre en cache du contenu géré, cela implique que les modifications du contenu sont uniquement visibles par les utilisateurs finaux une fois que la période de mise en cache configurée est arrivée à expiration et que le document est récupéré à partir de Dispatcher.

Pour un contrôle plus affiné, l’invalidation basée sur l’API vous permet d’invalider le cache d’un CDN si le cache de Dispatcher est invalidé. Sur la base de l’API du CDN, vous pouvez implémenter vos propres ContentBuilder et TransportHandler (si l’API n’est pas basée sur REST) et configurer un agent de réplication qui utilise ces derniers pour invalider le cache du CDN.

Utilisation de Dispatcher avec un serveur de création

/rules
{
/0000
{ /type "deny" /glob "*"}
}

Vous pouvez utiliser Dispatcher en regard d’une instance de création pour améliorer les performances de création. Pour configurer une instance Dispatcher de création, procédez comme suit :

1. Installez Dispatcher sur un serveur web (serveur web Apache ou IIS, voir Installation de Dispatcher).

2. Vous pouvez tester l’instance Dispatcher nouvellement installée par rapport à une instance de publication AEM afin de vous assurer que l’installation de la ligne de base est correcte.

3. Vérifiez ensuite que Dispatcher parvient à se connecter à l’instance de création via TCP/IP.

4. Remplacez l’exemple de fichier dispatcher.any par le fichier author_dispatcher.any, fourni avec le téléchargement de Dispatcher.

5. Ouvrez le author_dispatcher.any dans un éditeur de texte et apportez les modifications suivantes :

   1. Modifiez /hostname et /port dans la section /renders pour qu’ils pointent vers votre instance d’auteur.
   2. Modifiez /docroot dans la section /cache pour qu’il pointe vers un répertoire de cache. Si vous utilisez AEM avec l’interface utilisateur tactile, voir l’avertissement ci-dessus.
   3. Enregistrez les modifications.

6. Supprimez tous les fichiers existants dans le répertoire /cache > /docroot que vous avez configuré ci-dessus.

7. Redémarrez le serveur web.

1. Supprimez ou désactivez l’agent de purge de l’instance Dispatcher de création sur votre instance d’auteur AEM.
2. Rétablissez la configuration du Dispatcher de création en suivant les nouvelles instructions ci-dessus.

Ressources Business.Adobe.com

Automated Onboarding Style System Targeted Content Theme Editor Dynamic Media Digital Signage