Projet

Général

Profil

Anomalie #16838

[Ecran principal] Temps de chargement de dossiers virtuels

Ajouté par Cyril VAZQUEZ il y a environ 3 ans. Mis à jour il y a plus de 2 ans.

Statut:
R&D - Terminé
Priorité:
2-Sérieux
Assigné à:
-
Version cible:
Début:
12/04/2021
Echéance:
Tags RM:
2.7.3

Description

Lorsqu'une activité comporte beaucoup de dossiers virtuels (+10000) le chargement de l'arborescence est très long.

Analyse
Affichage par presenter recordsManagement/welcome/welcomePage

Voir délai pour l'appel au service 'filePlan/filePlan/readTree'
Voir délai de construction côté presenter html
Voir délai de construction du html par le JS

Selon les résultats:
* ne charger en back que le premier niveau et ajouter des routes pour charger le contenu d'un répertoire lorsque l'utilisateur l'ouvre
* charger toutes les niveaux mais seulement construire le html avec le JS lorsque l'utilisateur l'ouvre

Historique

#1 Mis à jour par Cyril VAZQUEZ il y a environ 3 ans

Pb lié à la traduction:

Quand l'instruction de fusion a pour cible non pas un noeud déjà présent mais un fragment, il n'est pas possible de traduire avant fusion.
La traduction a donc été faite après, mais sur la répétition de milliers d'éléments cela pose problème:

<?merge data /chemin/template.html ?>

Comme template est inclus au doc au moment de la fusion, il ne peut être traduit avant fusion.

Solution:
Nouvelle fonctions dans le système de templating pour ajouter des fragments au document sans les inclure dans l'arbre DOM
Modification de la fonction de traduction pour permettre de traduire ces fragments avant fusion
Modification du système de fusion pour utiliser en priorité les fragments déjà présents au lieu de les charger des fichiers à partir de l'URI précisée dans l'instruction de fusion

résultat = lorsque la fusion d'un tableau utilise une cible qui est un fragment, le fragment déjà présent et traduit est utilisé

#2 Mis à jour par Cyril VAZQUEZ il y a environ 3 ans

Second problème lié à la récursivité lors de la construction de l'arbre.

La lecture en DB renvoie un tableau de dossiers.
Le contrôleur fait appel à laabs::buildTree pour construire l'arbre.
laabs::buildTree fait appel à laabs::buildBranch récursivement

Création d'un buildTree2 qui n'est pas récursif mais utilise un nouveau tableau indexé par id d'objet

#3 Mis à jour par Alexandre GOLDSTEIN il y a environ 3 ans

7890

Tests réalisés à ce jour avec 10000 dossiers : on a 5 sec de délai sur la branche contenant la correction, le spinner ne s'arrete pas sur la branche develop (les dossiers ne sont jamais affichés)
Tests egalement fait avec 2000 dossiers : on a 2,22 sec de délai d'affichage sur la branche corrective, et 6.02 sec en comparaison sur la branche develop

#4 Mis à jour par Alexandre GOLDSTEIN il y a environ 3 ans

  • Statut changé de A traiter à A livrer

#5 Mis à jour par Cyril VAZQUEZ il y a environ 3 ans

  • Version cible changé de 2.7 à 2.7.3

#6 Mis à jour par Arnaud PAUGET il y a environ 3 ans

  • Statut changé de A livrer à Livré

#7 Mis à jour par Emmanuel DILLARD il y a presque 3 ans

  • Projet changé de Maarch RM - Product Backlog à Backlog RM
  • Version cible changé de 2.7.3 à 2.7
  • Tags RM 2.7.3 ajouté

#8 Mis à jour par Emmanuel DILLARD il y a plus de 2 ans

  • Statut changé de Livré à R&D - Terminé

Formats disponibles : Atom PDF