Projet

Général

Profil

Actions

Anomalie #16838

fermé

[Ecran principal] Temps de chargement de dossiers virtuels

Ajouté par Cyril VAZQUEZ il y a plus de 3 ans. Mis à jour il y a plus de 3 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

Fichiers

Mis à jour par Cyril VAZQUEZ il y a plus de 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é

Mis à jour par Cyril VAZQUEZ il y a plus de 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

Mis à jour par Alexandre GOLDSTEIN il y a plus de 3 ans

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

Mis à jour par Alexandre GOLDSTEIN il y a plus de 3 ans

  • Statut changé de A traiter à A livrer

Mis à jour par Cyril VAZQUEZ il y a plus de 3 ans

  • Version cible changé de 2.7 à 2.7.3

Mis à jour par Arnaud PAUGET il y a plus de 3 ans

  • Statut changé de A livrer à Livré

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Projet changé de 252 à Backlog RM
  • Version cible changé de 2.7.3 à 2.7
  • Tags RM 2.7.3 ajouté

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

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

Formats disponibles : Atom PDF