Purge du Dispatcher Adobe Managed Services

Ce document vous expliquera le processus de purge et le mécanisme qui permet la purge et l’invalidation du cache.

Principes de fonctionnement

Ordre des opérations

Le workflow classique est mieux décrit lorsque les auteurs de contenu activent une page, et une fois que l’éditeur reçoit le nouveau contenu, il envoie une requête de purge au répartiteur comme illustré dans le schéma suivant :

l’auteur active le contenu, ce qui amène l’éditeur à envoyer une requête de purge au répartiteur

Cet enchaînement d’événements souligne un point important : nous ne purgeons les éléments que lorsqu’ils sont nouveaux ou ont fait l’objet de modifications.  Cela permet de s’assurer que le contenu a été reçu par l’éditeur avant d’effacer le cache. De cette façon, vous évitez les conditions de concurrence où la purge pourrait survenir avant que les modifications puissent être prises en compte par l’éditeur.

Agents de réplication

Au niveau de l’auteur, un agent de réplication est configuré pour indiquer à l’éditeur que lorsqu’un élément est activé, il déclenche l’envoi du fichier vers cet éditeur, ainsi que toutes ses annexes.

Lorsque ce dernier reçoit le fichier, un agent de réplication est configuré pour l’indiquer au répartiteur qui déclenche l’événement à la réception.  Il sérialisera alors une requête de purge et l’enverra au répartiteur.

Agent de réplication de l’auteur

Voici quelques exemples de copies d’écran d’un agent de réplication standard configuré :

copie d’écran de l’agent de réplication standard sur la page web d’AEM /etc/replication.html

En général, 1 ou 2 agents de réplication sont configurés au niveau de l’auteur pour chaque éditeur vers lequel il réplique du contenu.

Le premier est l’agent de réplication standard qui redirige les activations de contenu.

Le deuxième est l’agent inverse.  Il est facultatif et configuré pour vérifier sur chaque boîte d’envoi des éditeurs si un nouveau contenu doit être transmis à l’auteur en tant qu’activité de réplication inverse.

Agent de réplication de l’éditeur

Voici un exemple de copies d’écran d’un agent de réplication de purge standard configuré :

copie d’écran de l’agent de réplication de purge standard sur la page web d’AEM /etc/replication.html

Réplication de purge du Dispatcher recevant un hôte virtuel

Le module du répartiteur recherche des en-têtes particuliers lui permettant de savoir quand une requête POST est un élément à transmettre aux rendus AEM ou s’il s’agit d’une requête sérialisée en tant que requête de purge qui doit être traitée par le gestionnaire du répartiteur lui-même.  Voici une copie d’écran de la page de configuration qui montre ces valeurs :

image de l’onglet des paramètres de l’écran principal de configuration avec le type de sérialisation affiché en tant que purge du Dispatcher

La page des paramètres par défaut affiche le Type de sérialisation en tant que Purge du Dispatcher et définit le niveau d’erreur.

Copie d’écran de l’onglet Transport de l’agent de réplication. Elle montre l’URI sur lequel envoyer la requête de purge. /dispatcher/invalidate.cache

Dans l’onglet Transport, vous pouvez voir que l’URI est configuré pour indiquer l’adresse IP du répartiteur qui recevra les requêtes de purge.  Le chemin d’accès /dispatcher/invalidate.cache ne permet pas au module de déterminer s’il s’agit d’une purge. Ce n’est qu’une extrémité manifeste visible dans le journal d’accès qui indique s’il s’agit d’une requête de purge.  Dans l’onglet Étendu, nous allons passer en revue les éléments permettant de déterminer s’il s’agit d’une requête de purge envoyée au module du répartiteur.

Copie d’écran de l’onglet Étendu de l’agent de réplication. Notez que les en-têtes sont envoyés avec la requête POST pour indiquer au répartiteur d’effectuer une purge.

La méthode HTTP pour les requêtes de purge n’est qu’une requête GET avec quelques en-têtes de requêtes spéciaux :

  • CQ-Action
    • Il utilise une variable AEM basée sur la requête. La valeur est généralement activée ou supprimée
  • CQ-Handle
    • Il utilise une variable AEM basée sur la requête. La valeur est généralement le chemin d’accès complet vers l’élément purgé, par exemple /content/dam/logo.jpg
  • CQ-Path
    • Il utilise une variable AEM basée sur la requête. La valeur est généralement le chemin d’accès complet vers l’élément à purger, par exemple /content/dam
  • Host
    • C’est ici que l’en-tête Host est copié pour cibler un <VirtualHost> spécifique configuré sur le serveur web Apache du répartiteur (/etc/httpd/conf.d/enabled_vhosts/aem_flush.vhost).  Il s’agit d’une valeur codée en dur qui correspond à une entrée dans le ServerName ou le ServerAlias du fichier aem_flush.vhost
Copie d’écran d’un agent de réplication standard montrant que ce dernier réagit et se déclenche lorsque de nouveaux éléments ont été reçus depuis un événement de réplication de l’auteur qui publie le contenu.

Dans l’onglet Déclencheurs, vous trouverez les déclencheurs activables que nous utilisons ainsi que leur fonction :

  • Ignorer par défaut
    • Cette option est activée pour que l’agent de réplication ne soit pas déclenché lors de l’activation d’une page.  Quand une instance d’auteur apporte une modification à une page, cela déclencherait une purge.  Comme c’est un éditeur, nous ne voulons pas déclencher ce genre d’événement.
  • À la réception
    • Lorsqu’un nouveau fichier est reçu, nous voulons déclencher une purge.  Ainsi, lorsque l’auteur nous envoie un fichier mis à jour, nous déclenchons et envoyons une requête de purge au répartiteur.
  • Aucun contrôle de version
    • Nous effectuons un contrôle pour éviter que l’éditeur ne génère de nouvelles versions en raison de la réception d’un nouveau fichier.  Nous remplacerons simplement le fichier existant et nous comptons sur l’auteur pour garder une trace des versions plutôt que sur l’éditeur.

Maintenant, si nous regardons à quoi ressemble une requête de purge classique sous la forme d’une commande cURL :

$ curl \ 
-H "CQ-Action: Activate" \ 
-H "CQ-Handle: /content/dam/logo.jpg" \ 
-H "CQ-Path: /content/dam/" \ 
-H "Content-Length: 0" \  
-H "Content-Type: application/octect-stream" \ 
-H "Host: flush" \ 
http://10.43.0.32:80/dispatcher/invalidate.cache

Dans cet exemple, le chemin d’accès /content/dam serait purgé au moyen d’une mise à jour du fichier .stat dans ce répertoire.

Le fichier .stat

Le mécanisme de purge est simple par nature et nous tenons à expliquer l’importance des fichiers .stat générés à la racine du document où les fichiers du cache sont créés.

Dans les fichiers .vhost et _farm.any, nous configurons une directive racine du document pour spécifier où se trouve le cache et où stocker/distribuer les fichiers quand une requête d’un utilisateur final est reçue.

Si vous deviez exécuter la commande suivante dans le serveur de votre répartiteur, vous commenceriez par trouver les fichiers .stat :

 

$ find /mnt/var/www/html/ -type f -name ".stat"

Voici un schéma de l’apparence de cette structure de fichier lorsque vous avez des éléments dans le cache et que le module du répartiteur a envoyé et traité une requête de purge :

fichiers .stat mélangés avec le contenu et dates affichées avec les niveaux des fichiers .stat

Niveau du fichier .stat

Notez que dans chaque répertoire, un fichier .stat était présent.  Cela indique qu’une purge a eu lieu.  Dans l’exemple ci-dessus, le paramètre statfilelevel a été défini sur 3 dans le fichier de configuration de la ferme correspondante.

Le paramètre statfilelevel indique combien de dossiers le module va parcourir et qu’il va mettre à jour un fichier .stat.  Le fichier.stat est vide. Ce n’est rien de plus qu’un nom de fichier avec un horodatage et il pourrait même être créé manuellement, en exécutant la commande tactile sur la ligne de commande du serveur du répartiteur.

Si le paramètre statfilelevel est réglé sur une valeur trop élevée, alors chaque requête de purge parcourt l’arborescence du répertoire en affectant les fichiers .stat.  Cela peut devenir une performance majeure au niveau des grandes arborescences du cache et avoir un impact sur la performance globale de votre répartiteur.

Si vous réglez ce niveau de fichier sur une valeur trop basse, une requête de purge peut supprimer plus de données que prévu.  Ce qui, par conséquent, provoquerait une perte de mémoire cache plus fréquente avec moins de requêtes traitées à partir du cache et pourrait entraîner des problèmes de performance.

Remarque :

Définissez le paramètre statfilelevel à un niveau raisonnable.  Examinez la structure de vos dossiers et assurez-vous qu’elle est configurée de façon à garantir des purges précises sans avoir à parcourir trop de dossiers.   Vérifiez-la et assurez-vous qu’elle correspond à vos besoins lors d’un test de performance du système.

Comme exemple, prenons le cas d’un site qui prend en charge plusieurs langues.  L’arborescence de contenu classique comporterait les répertoires suivants :

/content/brand1/en/us/

Dans cet exemple, utilisez un paramètre statfilelevel défini sur 4.  Ainsi, lorsque vous purgez le contenu se trouvant sous le dossier us, vous êtes assuré que les dossiers de langue ne seront pas purgés.

Protocole Handshake de l’horodatage des fichiers .stat

Lorsqu’une requête de contenu se présente, la même routine se répète :

  1. L’horodatage du fichier .stat est comparé à l’horodatage du fichier requis.
  2. Si le fichier .stat est plus récent que le fichier requis, il supprime le contenu mis en cache et en récupère un nouveau dans AEM, puis le met en cache.  Ensuite, il diffuse le contenu.
  3. Si le fichier .stat est plus ancien que le fichier requis, cela signifie que le fichier est récent et que le contenu peut être diffusé.

Protocole Handshake du cache - Exemple 1

Dans l’exemple ci-dessus, voici une requête pour le contenu /content/index.html

Le fichier index.html est daté du 01/11/2019 à 18h30

Le fichier .stat le plus proche est daté du 01/11/2019 à 12h22

Avec ce que nous avons vu précédemment, vous pouvez constater que le fichier d’index est plus récent que le fichier .stat et qu’il sera transmis du cache à l’utilisateur final qui le demande.

Protocole Handshake du cache - Exemple 2

Dans l’exemple ci-dessus, voici une requête pour le contenu /content/dam/logo.jpg

Le fichier logo.jpg est daté du 31/10/2019 à 13h13

Le fichier .stat le plus proche est daté du 01/11/2019 à 12h22

Dans cet exemple, le fichier est plus ancien que le fichier .stat et sera supprimé. Un nouveau fichier sera extrait d’AEM pour le remplacer dans le cache avant d’être transmis à l’utilisateur final qui le demande.

Paramètres du fichier de ferme

La documentation est disponible pour l’ensemble des options de configuration : https://docs.adobe.com/content/help/fr-FR/experience-manager-dispatcher/using/configuring/dispatcher-configuration.html#configuring-dispatcher_configuring-the-dispatcher-cache-cache

Nous tâcherons de mettre en évidence quelques-unes d’entre elles qui se rapportent à la purge du cache.

Racine du document

Cette entrée de configuration se trouve dans la section suivante du fichier de ferme :

/myfarm { 
    /cache { 
        /docroot

Vous spécifiez le répertoire dans lequel vous voulez voir le répartiteur être renseigné et géré comme un répertoire du cache.

Remarque :

Ce répertoire doit correspondre au paramètre racine du document apache pour le domaine que votre serveur web doit utiliser.

Avoir des dossiers docroot imbriqués pour chaque ferme qui se trouvent dans un sous-dossier de la racine du document apache n’est pas une bonne idée, et ce pour plusieurs raisons.

Niveau des fichiers .stat

Cette entrée de configuration se trouve dans la section suivante du fichier de ferme :

/myfarm { 
    /cache { 
        /statfileslevel

Ce paramètre évalue jusqu’à quel niveau les fichiers .stat devront être générés lorsqu’une requête de purge est reçue.

/statfileslevel défini au nombre suivant avec la racine du document /var/www/html/ obtiendrait les résultats suivants lors de la purge du fichier /content/dam/brand1/en/us/logo.jpg

  • 0 - Les fichiers .stat suivants seraient créés :
    • /var/www/html/.stat
  • 1 - Les fichiers .stat suivants seraient créés :
    • /var/www/html/.stat
    • /var/www/html/content/.stat
  • 2 - Les fichiers .stat suivants seraient créés :
    • /var/www/html/.stat
    • /var/www/html/content/.stat
    • /var/www/html/content/dam/.stat
  • 3 - Les fichiers .stat suivants seraient créés :
    • /var/www/html/.stat
    • /var/www/html/content/.stat
    • /var/www/html/content/dam/.stat
    • /var/www/html/content/dam/brand1/.stat
  • 4 - Les fichiers .stat suivants seraient créés :
    • /var/www/html/.stat
    • /var/www/html/content/.stat
    • /var/www/html/content/dam/.stat
    • /var/www/html/content/dam/brand1/.stat
    • /var/www/html/content/dam/brand1/en/.stat
  • 5 - Les fichiers .stat suivants seraient créés :
    • /var/www/html/.stat
    • /var/www/html/content/.stat
    • /var/www/html/content/dam/.stat
    • /var/www/html/content/dam/brand1/.stat
    • /var/www/html/content/damn/brand1/en/.stat
    • /var/www/html/content/damn/brand1/en/us/.stat

 

Remarque :

Pour rappel, lorsque le protocole Handshake de l’horodatage se déclenche, il recherche le fichier .stat le plus proche.

Avoir un fichier .stat de niveau 0 et un fichier .stat uniquement sur /var/www/html/.stat signifie que le contenu se trouvant sous /var/www/html/content/dam/brand1/en/us/ chercherait le fichier .stat le plus proche et parcourrait 5 dossiers pour trouver le seul fichier .stat qui existe au niveau 0 et comparer les dates à celui-ci.  Ce qui veut dire qu’une purge dont le niveau est aussi élevé invaliderait pratiquement tous les éléments mis en cache.

Invalidation autorisée

Cette entrée de configuration se trouve dans la section suivante du fichier de ferme :

/myfarm { 
    /cache { 
        /allowedClients {

Dans cette configuration se trouve une liste d’adresses IP autorisées à envoyer des requêtes de purge.  Si une requête de purge est transmise au répartiteur, elle doit provenir d’une adresse IP de confiance.  Si vous n’avez pas la bonne configuration ou si vous envoyez une requête de purge à partir d’une adresse IP non sécurisée, l’erreur suivante s’affiche dans le fichier journal :

[Mon Nov 11 22:43:05 2019] [W] [pid 3079 (tid 139859875088128)] Flushing rejected from 10.43.0.57

Règles d’invalidation

Cette entrée de configuration se trouve dans la section suivante du fichier de ferme :

/myfarm { 
    /cache { 
        /invalidate {

Ces règles indiquent généralement quels fichiers peuvent être invalidés avec une requête de purge.

Pour éviter que des fichiers importants ne soient invalidés lors de l’activation d’une page, vous pouvez établir des règles qui spécifient quels fichiers peuvent être invalidés et lesquels doivent l’être manuellement.  Voici un exemple de configuration qui ne permet d’invalider que les fichiers html :

/invalidate { 
   /0000 { /glob "*" /type "deny" } 
   /0001 { /glob "*.html" /type "allow" } 
}

Test/Dépannage

Lorsque vous activez une page et que vous obtenez le feu vert indiquant que l’activation de la page a réussi, vous devez vous attendre à ce que le contenu activé soit supprimé du cache également.

Vous actualisez votre page et voyez l’ancien contenu. Ce n’est pas possible ! Aviez-vous eu le feu vert ?

Suivons quelques étapes manuelles du processus de purge pour nous éclairer sur les problèmes éventuels.  À partir du shell de l’éditeur, exécutez la requête de purge suivante à l’aide de la commande cURL :

 

$ curl -H "CQ-Action: Activate" \ 
-H "CQ-Handle: /content/<PATH TO ITEM TO FLUSH>" \ 
-H "CQ-Path: /content/<PATH TO ITEM TO FLUSH>" \ 
-H "Content-Length: 0" -H "Content-Type: application/octet-stream" \ 
-H "Host: flush" \ 
http://<DISPATCHER IP ADDRESS>/dispatcher/invalidate.cache

Exemple de test de la requête de purge :

$ curl -H "CQ-Action: Activate" \ 
-H "CQ-Handle: /content/customer/en-us" \ 
-H "CQ-Path: /content/customer/en-us" \ 
-H "Content-Length: 0" -H "Content-Type: application/octet-stream" \ 
-H "Host: flush" \ 
http://169.254.196.222/dispatcher/invalidate.cache

Une fois que vous avez envoyé la commande de requête au répartiteur, vous voudrez voir ce qui se passe dans les journaux et avec les fichiers .stat.  Parcourez le fichier journal. Les entrées suivantes devraient s’afficher pour confirmer l’accès de la requête de purge dans le module du répartiteur.

[Wed Nov 13 16:54:12 2019] [I] [pid 19173:tid 140542721578752] Activation detected: action=Activate [/content/dam/logo.jpg] 
[Wed Nov 13 16:54:12 2019] [I] [pid 19173:tid 140542721578752] Touched /mnt/var/www/html/.stat 
[Wed Nov 13 16:54:12 2019] [I] [pid 19173:tid 140542721578752] Touched /mnt/var/www/html/content/.stat 
[Wed Nov 13 16:54:12 2019] [I] [pid 19173:tid 140542721578752] Touched /mnt/var/www/html/content/dam/.stat 
[Wed Nov 13 16:54:12 2019] [I] [pid 19173:tid 140542721578752] "GET /dispatcher/invalidate.cache" 200 purge [publishfarm/-] 0ms

Maintenant que le module a été récupéré et qu’il a accusé réception de la requête de purge, nous devons voir en quoi elle affecte les fichiers .stat.  Exécutez la commande suivante et observez la mise à jour des horodatages au fur et à mesure que vous lancez une autre purge :

$ watch -n 3 "find /mnt/var/www/html/ -type f -name ".stat" | xargs ls -la $1"

Horodatages des fichiers .stat actuels, comme vous pouvez le voir depuis la sortie de commande

-rw-r--r--. 1 apache apache 0 Nov 13 16:54 /mnt/var/www/html/content/dam/.stat 
-rw-r--r--. 1 apache apache 0 Nov 13 16:54 /mnt/var/www/html/content/.stat 
-rw-r--r--. 1 apache apache 0 Nov 13 16:54 /mnt/var/www/html/.stat

Si nous relançons la purge, la mise à jour de l’horodatage sera visible.

-rw-r--r--. 1 apache apache 0 Nov 13 17:17 /mnt/var/www/html/content/dam/.stat 
-rw-r--r--. 1 apache apache 0 Nov 13 17:17 /mnt/var/www/html/content/.stat 
-rw-r--r--. 1 apache apache 0 Nov 13 17:17 /mnt/var/www/html/.stat

Comparons les horodatages de notre contenu avec ceux de nos fichiers .stat.

$ stat /mnt/var/www/html/content/customer/en-us/.stat 
  File: `.stat' 
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file 
Device: ca90h/51856d    Inode: 17154125    Links: 1 
Access: (0644/-rw-r--r--)  Uid: (   48/  apache)   Gid: (   48/  apache) 
Access: 2019-11-13 16:22:31.000000000 -0400 
Modify: 2019-11-13 16:22:31.000000000 -0400 
Change: 2019-11-13 16:22:31.000000000 -0400 
 
$ stat /mnt/var/www/html/content/customer/en-us/logo.jpg 
File: `logo.jpg' 
  Size: 15856           Blocks: 32          IO Block: 4096   regular file 
Device: ca90h/51856d    Inode: 9175290    Links: 1 
Access: (0644/-rw-r--r--)  Uid: (   48/  apache)   Gid: (   48/  apache) 
Access: 2019-11-11 22:41:59.642450601 +0000 
Modify: 2019-11-11 22:41:59.642450601 +0000 
Change: 2019-11-11 22:41:59.642450601 +0000

Si vous regardez les horodatages, vous remarquerez que le contenu est plus récent que le fichier .stat. Ce dernier indique au module de distribuer le fichier du cache, car il est plus récent.

Autrement dit, un élément a mis à jour les horodatages de ce fichier, ce qui ne le qualifie pas comme étant « purgé » ou remplacé.

Suivant ➡ URL Vanity

Logo Adobe

Accéder à votre compte