Problèmes courants liés à l’ingestion des ressources et solutions
Cet article décrit les scénarios d’ingestion de ressources d’AEM les plus courants et comment les analyser, y compris le traitement élevé, le volume élevé, les référentiels DAM volumineux et de nombreux auteurs simultanés.
Description description
Environnement
Adobe Experience Manager (AEM)
Problème
Cet article décrit les scénarios d’ingestion de ressources d’AEM les plus courants et comment les analyser pour :
- Traitement élevé
- Volume élevé
- Référentiels DAM volumineux
- De nombreux auteurs simultanés
Résolution resolution
Scénarios d’ingestion et solutions
Scénario 1 : traitement élevé
Des situations telles que les importations massives, telles que 2 000 images à la fois, provoquent un processeur et une mémoire élevés pour les instances d’auteur.
Solution
Déchargez les tâches vers une autre instance AEM. Vous pouvez décharger des workflows entiers ou seulement quelques étapes lourdes en connectant l’instance de traitement aux instances d’auteur principales via les programmes de traitement par proxy de gestion des actifs numériques. L’instance de création principale reste ainsi libre de servir d’autres utilisateurs. Les agents proxy de la gestion des actifs numériques sont chargés de la supervision des tâches distantes, de la collecte des résultats et de leur alimentation à l’exécution du workflow local.
Scénario 2 : volume élevé
Il s’agit d’instances où une base de données de quelques millions de produits comporte 12 000 modifications par jour. Le référentiel devient le goulot d’étranglement dans de tels scénarios. Pendant que les écritures sont en cours, les lectures sont bloquées à des fins de cohérence.
Solution
Pour éviter cette situation, séparez le processus d’importation sur une instance d’auteur dédiée avec son propre référentiel. Une fois l’opération terminée, répliquez un delta complet dans l’environnement de création, avec réplication en chaîne dans l’environnement de publication, si nécessaire. Utilisez une file d’attente de réplication réservée pour éviter de retarder les modifications éditoriales importantes de la publication.
Scénario 3 : référentiels DAM volumineux
Cela se produit avec d’énormes référentiels, tels que plus de 7 millions de ressources, 20 millions de noeuds et une taille de disque de 15 To. Cela a un impact sur les performances de l’instance.
Solution
Fractionner le magasin persistant et le magasin de données (optimisé pour gérer les fichiers binaires volumineux). Le magasin persistant nécessite une très faible latence d’E/S, donc le stockage local fonctionne mieux. Pour l’entrepôt de données, une latence plus élevée est acceptable.
Scénario 4 : plusieurs auteurs simultanés
De nombreux auteurs simultanés peuvent avoir un impact sur les performances et le traitement.
Solution
Les auteurs simultanés sont des utilisateurs qui travaillent activement sur le système. Les auteurs connectés mais inactifs ne placent pas de charge supplémentaire sur le système. Opérations telles que la modification, le chargement de ressources, le déclenchement du processeur de workflows, la mémoire, la recherche et le téléchargement de ressources, ainsi que la modification des métadonnées.
La formation d’un cluster d’instances d’auteur avec un dispatcher au premier plan permet de répartir uniformément la charge du processeur. Avec un grand nombre d’auteurs en production active, il est recommandé de diviser chaque projet en une instance ou un environnement de création distinct dans lequel le travail en cours a lieu. Cette technique est appelée partitionnement de contenu.
Poser Des Questions Dans Notre Communauté Campaign Experience League
Si vous avez des questions auxquelles vous souhaitez répondre à propos de ce sujet ou si vous avez des questions auxquelles vous avez déjà répondu, nous vous invitons à consulter notre article de blog de la communauté Experience League qui comprend cet article, à nous envoyer vos questions et commentaires, et à rejoindre notre communauté Campaign Experience League !