Environnement
Experience Manager
Problème/Symptômes
Ce document fournit des conseils sur la façon dont la purge se produit et explique le mécanisme qui exécute la purge du cache et l’invalidation.
Fonctionnement
Ordre des opérations
Le workflow type est mieux décrit lorsque les auteurs de contenu activent une page. Lorsque l’éditeur reçoit le nouveau contenu, il déclenche une demande de purge au répartiteur, comme illustré dans le diagramme suivant :
Cet enchaînement d’événements souligne que nous ne vidons les éléments que lorsqu’ils sont nouveaux ou ont changé. Cela permet de s’assurer que le contenu a été reçu par l’éditeur avant d’effacer le cache afin d’éviter les conditions de concurrence dans lesquelles le vidage peut se produire avant que les modifications ne puissent être récupérées auprès de l’éditeur.
Agents de réplication
Sur l’instance de création, 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 et de toutes ses dépendances à l’éditeur.
Lorsque l’éditeur reçoit le fichier, un agent de réplication est configuré pour pointer vers le Dispatcher qui se déclenche sur l’événement à la réception. Il sérialisera ensuite une requête de purge et la publiera dans le Dispatcher.
AGENT DE RÉPLICATION DE L’AUTEUR
Voici quelques exemples de captures d’écran d’un agent de réplication standard configuré
Il existe généralement 1 ou 2 agents de réplication configurés sur l’auteur pour chaque éditeur vers lequel ils répliquent du contenu.
Tout d’abord, il s’agit de l’agent de réplication standard qui envoie les activations de contenu à .
Le second est l’agent inverse. Cette option est facultative et configurée pour vérifier dans la boîte d’envoi de chaque éditeur s’il existe un nouveau contenu à extraire dans l’auteur en tant qu’activité de réplication inverse.
AGENT DE RÉPLICATION DE L’ÉDITEUR
Voici un exemple de captures d’écran d’un agent de réplication de purge standard configuré
RÉPLICATION DE FLUX DE DISPATCHER REÇANT UN HÔTE VIRTUEL
Le module de Dispatcher recherche des en-têtes particuliers à connaître lorsqu’une demande de POST doit être transmise aux rendus AEM ou s’il s’agit d’une demande sérialisée en tant que demande de purge et qui doit être traitée par le gestionnaire de Dispatcher lui-même. Voici une capture d’écran de la page de configuration qui affiche ces valeurs :
La page des paramètres par défaut affiche la variable Type de sérialisation as Purge du Dispatcher et définit le niveau d’erreur
Dans l’onglet Transport, vous pouvez voir l’URI défini pour pointer l’adresse IP du Dispatcher qui recevra les requêtes de purge. Le chemin /dispatcher/invalidate.cache n’est pas la manière dont le module détermine s’il s’agit d’une purge. Il s’agit uniquement d’un point de terminaison évident que vous pouvez voir dans le journal d’accès pour savoir qu’il s’agissait d’une requête de purge. Dans l’onglet Étendu , nous allons passer en revue les éléments qui sont là pour vérifier qu’il s’agit d’une requête de purge envoyée au module de Dispatcher.
La méthode HTTP pour les requêtes de vidage est simplement une requête GET avec certains en-têtes de requête spéciaux :
CQ-Action
CQ-Handle
CQ-Path
Hôte
Maintenant, si nous regardons à quoi ressemble une requête de purge standard 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 |
---|
Cet exemple de purge purge le chemin d’accès /content/dam en mettant à jour le fichier .stat dans ce répertoire.
Le fichier .stat
Le mécanisme de purge est simple par nature et nous voulons expliquer l'importance de .stat fichiers générés à la racine du document dans laquelle les fichiers de 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/servir les fichiers lorsqu’une demande d’un utilisateur final arrive.
Si vous exécutez la commande suivante sur votre serveur Dispatcher, vous commencerez à rechercher des fichiers .stat.
1 | $ find /mnt/var/www/html/ - type f -name ".stat" |
---|
Voici un diagramme de l’apparence de cette structure de fichiers lorsque vous avez des éléments dans le cache et qu’une demande de purge a été envoyée et traitée par le module de Dispatcher.
NIVEAU DU FICHIER STADE
Notez que dans chaque répertoire, un fichier .stat était présent. Il s’agit d’un indicateur indiquant qu’une purge a eu lieu. Dans l’exemple ci-dessus, statfilelevel a été défini sur 3 dans le fichier de configuration de ferme correspondant.
Le paramètre statfilelevel indique le nombre de dossiers que le module parcourra en profondeur et met à jour un fichier .stat. Le fichier .stat est vide. Il ne s’agit rien de plus qu’un nom de fichier avec un horodatage et peut même être créé manuellement, mais il exécute la commande tactile sur la ligne de commande du serveur Dispatcher.
Si le paramètre de niveau de fichier stat est défini sur une valeur trop élevée, chaque requête de purge traverse l’arborescence de répertoires pour toucher les fichiers .stat. Cela peut devenir un accès aux performances majeur sur les grandes arborescences du cache et avoir une incidence sur les performances globales de votre dispatcher.
Si vous définissez ce niveau de fichier sur une valeur trop basse, une requête de purge peut effacer plus que prévu. Ce qui, à son tour, provoquerait l’exécution du cache plus souvent avec moins de requêtes diffusées à partir du cache et peut entraîner des problèmes de performances.
Remarque :
Définissez le niveau du fichier stat à un niveau raisonnable. Examinez la structure de vos dossiers et assurez-vous qu’elle est configurée pour permettre des vidages concis sans avoir à parcourir trop de répertoires. Testez-le et assurez-vous qu’il correspond à vos besoins lors d’un test de performance du système.
Un bon exemple est un site qui prend en charge les langues. L’arborescence de contenu classique contiendra les répertoires suivants :
/content/brand1/fr/us/
Dans cet exemple, utilisez un paramètre de niveau fichier stat de 4. Cela vous assure lorsque vous videz du contenu qui se trouve sous la balise us pour empêcher le vidage des dossiers de langue.
GESTION DE L’HORODATAGE DU FICHIER STADE
Lorsqu’une demande de contenu entre dans la même routine se produit
GESTION DU CACHE - EXEMPLE 1
Dans l’exemple ci-dessus, une requête pour le contenu /content/index.html
L'heure du fichier index.html est 2019-11-01 à 18h21
L’heure du fichier .stat le plus proche est 2019-11-01 @ 22h22
En comprenant ce que nous avons lu ci-dessus, vous pouvez constater que le fichier d’index est plus récent que le fichier .stat et que le fichier est transmis du cache à l’utilisateur final qui l’a demandé.
GESTION DU CACHE - EXEMPLE 2
Dans l’exemple ci-dessus, une requête pour le contenu /content/dam/logo.jpg
L’heure du fichier logo.jpg est 2019-10-31 à 13h13.
L’heure du fichier .stat le plus proche est 2019-11-01 @ 22h22
Comme vous pouvez le voir dans cet exemple, le fichier est plus ancien que le fichier .stat et sera supprimé et un nouveau fichier extrait de l’AEM pour le remplacer dans le cache avant d’être envoyé à l’utilisateur final qui l’a demandé.
Paramètres du fichier de ferme
La documentation est disponible ici 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 allons mettre en évidence quelques-uns d’entre eux 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 souhaitez que Dispatcher soit renseigné et géré en tant que répertoire de cache.
Remarque :
Ce répertoire doit correspondre au paramètre racine du document Apache pour le domaine que votre serveur web est configuré pour utiliser.
Avoir des dossiers docroot imbriqués pour chaque ferme qui vivent des sous-dossiers de la racine du document apache est une idée terrible pour de nombreuses raisons.
Niveau de fichier d’état
Cette entrée de configuration se trouve dans la section suivante du fichier de ferme :
/myfarm { /cache { /statfileslevel |
---|
/statfileslevel défini au numéro suivant avec la racine du document /var/www/html/ aurait les résultats suivants lors de la purge /content/dam/brand1/en/us/logo.jpg
0 - Les fichiers .stat suivants seraient créés :
1 - Les fichiers .stat suivants seraient créés :
2 - Les fichiers .stat suivants seraient créés :
3 - Les fichiers .stat suivants seraient créés :
4 - Les fichiers .stat suivants seraient créés :
5 - Les fichiers .stat suivants seraient créés :
Remarque :
Gardez à l’esprit que lorsque la poignée de main d’horodatage se produit, il recherche le fichier .stat le plus proche.
avoir un fichier .stat de niveau 0 et un fichier .stat uniquement à l’adresse /var/www/html/.stat signifie que le contenu situé sous /var/www/html/content/dam/brand1/fr/us/ rechercherait le fichier .stat le plus proche et parcourrait 5 dossiers pour trouver le seul fichier .stat existant au niveau 0 et comparer les dates à celui-ci. Cela signifie qu’une purge à ce niveau élevé invaliderait essentiellement 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, vous placez une liste d’adresses IP autorisées à envoyer des requêtes de purge. Si une requête de purge entre dans le Dispatcher, elle doit provenir d’une adresse IP de confiance. Si vous avez mal configuré ou si vous envoyez une requête de purge à partir d’une adresse IP non approuvée, l’erreur suivante s’affichera 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 avec l’activation d’une page, vous pouvez appliquer des règles qui spécifient quels fichiers peuvent être invalidés et lesquels doivent être invalidés manuellement. Voici un exemple de configuration qui autorise uniquement l’invalidation des fichiers HTML :
/invalidate { /0000 { /glob "*" /type "deny" } /0001 { /glob "*.html" /type "allow" } } |
---|
Tests/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 que vous avez activé soit également vidé du cache.
Vous actualisez votre page et voyez les anciennes choses et il y a le feu vert.
Suivons quelques étapes manuelles du processus de purge pour nous donner une idée de ce qui pourrait être mauvais. Dans le shell de l’éditeur, exécutez la requête de purge suivante à l’aide de 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 requête de purge de test
$ 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 déclenché la commande de requête vers le Dispatcher, vous souhaiterez voir ce qui est fait dans les journaux et ce qui est fait avec les fichiers .stat. Suivez le fichier journal et vous devriez voir les entrées suivantes pour confirmer que la demande de purge a atteint le module de Dispatcher.
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 est récupéré et que la demande de vidage a été acquittée, nous devons voir comment il a affecté les fichiers .stat. Exécutez la commande suivante et observez la mise à jour des horodatages lorsque vous lancez une autre purge :
| $
watch
-n 3
"find /mnt/var/www/html/ -type f -name "
.stat
" | xargs ls -la $1"
|
| — |
Comme vous pouvez le voir à partir de la sortie de la commande, les horodatages des fichiers .stat actuels
-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 |
---|
Maintenant, si nous réexécutons la purge, vous verrez la mise à jour des horodatages.
-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 nos horodatages de contenu aux horodatages de nos fichiers .stat
$ stat /mnt/var/www/html/content/customer/en-us/ .stat File: .stat’ Taille : 0 blocs : Bloc 0 E/S : 4096 normal videfile Appareil : ca90h/51856d` `Inode: 17154125 Links: 1 Accès : (0644)/-rw-r--r-- ) Uid : ( 48/ apache) Gid : ( 48/ apache)Access: 2019-11-13 16:22:31.000000000 -0400 Modifier : 2019-11-13 16:22:31.000000000 -0400Change: 2019-11-13 16:22:31.000000000 -0400`<br> <br>`$ stat /mnt/var/www/html/content/customer/fr-fr/logo.jpg Fichier : 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 examinez l’un des horodatages, vous remarquerez que le contenu a une heure plus récente que le fichier .stat qui indique au module de servir le fichier à partir du cache, car il est plus récent que le fichier .stat.
En clair, quelque chose a mis à jour les horodatages de ce fichier qui ne le qualifient pas pour être "purgé" ou remplacé.