nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Exécution d'un patch : problème de performances

mlagneaux

Bonjour,

J'ai développé un patch qui permet de remplacer les valeurs d'une propriété "Statut". A chaque ancienne valeur possible pour cette propriété, je fais correspondre la nouvelle valeur.
Mon patch balaye tous les noeuds de type "content" de l'entrepôt (ils sont récupérés via une requête Lucene), récupère la valeur actuelle du statut, en déduit la nouvelle valeur et valorise la propriété "Statut" du noeud avec cette nouvelle valeur. Les actions sur les noeuds sont réalisées via le nodeService.

J'ai ajouté dans ce patch la désactivation des behaviours liées à l'aspect auditable pour que la date de modification des noeuds traités ne change pas (je les réactive à la fin du patch) ainsi que des traces dans la log apparaissant tous les 1000 noeuds traités.

J'exécute actuellement ce patch sur un entrepôt contenant 300000 documents. Ce patch tourne depuis maintenant plus d'une journée et on remarque grâce aux traces que plus le temps passe et plus les performances diminuent (le temps pour traiter 1000 noeuds est de plus important : il augmente de façon exponentielle).

Qu'est-ce qui pourrait expliquer cette chute en terme de performance ?
Y a-t-il des paramètres au niveau d'Alfresco pouvant améliorer les performances ?

Find more posts tagged with

Comments

rguinot

La requête lucene n'est à mon avis pas la bonne piste à suivre, surtout si vous requetez l'ensemble de l'entrepot à chaque fois …
Plusieurs solutions seraient + efficaces, comme par exemple parcourir l'arbre recursivement a l'aide du FileFolderService, ou bien parcourir la table des transactions, et traiter les noeuds concernés par les différentes transactions. Avec cette approche vous pourriez également parallèliser les traitements en distribuant des lots de transactions à différents threads d'un pool de threads

Inspirez vous des patchs existants qui utilisent ces approches.

mlagneaux

J'ai modifié mon patch en me basant sur FixNameCrcValuesPatch. Je récupère maintenant la liste des id (dans la base alf_node) à traiter via une requête exécutée via hibernate.
Par la suite, je balaye tous ces id. Pour chacun, je recrée un objet de type Node, j'obtiens son nodeRef et je mets à jour la propriété Statut via le nodeService.

Suite à un test sur un dépôt contenant 20000 documents, le patch semble plus rapide (environ 2 fois). Par contre, ce qui prend du temps, c'est le commit de la transaction qui est fait à l'issue du patch.

Est-il possible de gagner du temps sur le commit ?
Y a-t-il plus rapide que le nodeService pour mettre à jour la propriété ? Cette propriété est indexée, j'ai donc besoin que les noeuds traités soient réindexés après la mise à jour du statut.

Merci d'avance pour l'aide sur ce sujet.

mlagneaux

Je considère ce post comme "Résolu".
Utiliser une requête SQL (au lieu d'une requête Lucene) pour récupérer les noeuds à traiter a largement amélioré les performances de mon patch : sur un dépôt de 300 000 noeuds, il s'est exécuté en moins de 7h contre plus de 48h à l'origine.