Objectif

Cet article décrit les erreurs d’assimilation des actifs AEM les plus courantes et la façon dont les analyser.

  • Traitement élevé
  • Volume élevé
  • Référentiels DAM volumineux.
  • Plusieurs auteurs concurrents

Hypothèses et solutions d’ingestion

Hypothèse 1 : Traitement élevé

Des situations, telles que les importations en masse de 2000 images d’un coup, provoquent une utilisation UC et mémoire élevée pour les instances d’auteur.

Solution : Déchargement des tâches sur une autre instance AEM. Vous pouvez décharger des flux de production entiers ou seulement quelques étapes importantes en connectant l’instance de traitement aux instances d’auteur principales via des opérateurs de proxy DAM. L’instance principale de l’auteur reste libre pour servir d’autres utilisateurs. Les opérateurs de proxy DAM sont en charge de la supervision des tâches distantes, de la collecte des résultats et pour les alimentées au flux de production local.

 

Hypothèse 2 : Volume élevé

Instances où la base de données de quelques millions de produits comporte 12 000 modifications par jour. Le référentiel devient les curseurs dans ces hypothèses. Lorsque l’écriture est en cours d’exécution, 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, vous devez répliquer un delta complet dans l’environnement auteur avec une réplication enchaînée, le cas échéant. Utilisez une file d’attente de réplication réservée pour éviter de retarder des modifications éditoriales importantes de la publication.

 

Hypothèse 3 : Grands référentiels DAM.D’énormes référentiels, tels que plus de 7 millions d’actifs, 20 millions de nœuds et une taille de disque de 15 To. Cela affecte les performances de l’occurrence.

Solution : Divisez le stockage persistant et le stockage de données (optimisé pour la gestion des fichiers binaires volumineux). Le stockage persistant nécessite une latence très faible, en conséquence le stockage local fonctionne mieux. Pour le stockage de données, une latence plus élevée est acceptable.

 

Hypothèse 4 : De nombreux auteurs concurrents 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 téléchargement de fichiers, le traitement de flux de production, la mémoire, la recherche et le téléchargement des actifs, la modification des métadonnées. La simplicité d’instances d’auteur à l’aide d’un répartiteur placé dans la partie avant aide à répartir le charge de l’unité centrale de façon égale. Avec un grand nombre d’auteurs de la production active, il est recommandé de faire glisser les différents projets dans une instance d’auteur ou un environnement distinct dans lequel le travail a lieu. Cette technique est nommée partitionnement de contenu.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne