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.
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
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é
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
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
- Statut changé de A traiter à A livrer
- Version cible changé de 2.7 à 2.7.3
- Statut changé de A livrer à Livré
- Projet changé de 252 à Backlog RM
- Version cible changé de 2.7.3 à 2.7
- Tags RM 2.7.3 ajouté
- Statut changé de Livré à R&D - Terminé
Formats disponibles : Atom
PDF