Performances de chargement et de navigation

[camillemonchicourt]

Dans le cadre du groupement de commandes 2019-2021 a travail a été initié pour améliorer les performances de chargement des objets dans l'interface de Geotrek-admin et donc de navigation dans l'outil.

Le projet a été détaillé ici : https://github.com/GeotrekCE/Geotrek-admin/projects/2
Et les développements réalisés : #2387

Les développements ne sont pas terminés et une nouvelle phase de développement a été lancée pour pouvoir aboutir à des premières améliorations de ces performances.

Pour cela une analyse technique a été réalisée par @submarcos :
MakinaCorpus Perfs Retour 2j jpo 20220210.pdf

Les actions envisagées sont :

1. Mettre en place la pagination côté serveur sur les listes de données
2. Utiliser Django-RestFramework-GIS pour générer les GeoJSON

• premier pas vers le tuilage qui améliorera les performances, car la génération du GeoJSON se fera en un coup côté Base de données PostGIS, et pas élément par élément dans le code Python

3. Séparer les tronçons ‘brouillon’ dans une nouvelle sous-liste du module tronçon (nouveau modèle de données)
4. Mettre à jour les bibliothèques Leaflet (cette étape est déjà initiée et peut se dérouler en parallèle des premières étapes, du moins sur la partie des bibliothèques en elle- même et pas de leur utilisation dans Geotrek)
5. Mettre en place le tuilage des données cartographiques (en fonction de la faisabilité rapide, GeoJSON ou MVT)

[submarcos]

Quelques précisions suites au début des développements :

• Contrairement à ce que j'ai indiqué dans le document, le cache ne s'invalide pas au bout de 8jours, mais au bout de 8h. Il faudrait surement augmenter sensiblement cette valeur (30j ?) en attendant d'ameliorer la gestion globale de ce cache
• Il est surement possible d'améliorer la création d'itinéraires sans pour autant séparer les tronçons brouillons dans une autre couche de données, par exemple en utilisant le meme geojson en cache, mais en n'affichant pas les brouillons sur les tracés linéaires topologiques ( à tester sur un gros volume de données)
• L'imbrication des points 1 et 2 du document est telle que je vais surement devoir les réaliser en meme temps.

PR des modifications coté mapentity : makinacorpus/django-mapentity#228
(en cours, je vais commencer son intégration coté geotrek et apporterai toutes les corrections nécessaires en suivant)

[camillemonchicourt]

OK merci pour ces premiers retours.
En effet si le cache est remis à zéro dans tous les cas quand il y a une modification d'un objet, quand il n'y a pas de modification autant le garder plus que 8 heures.

[submarcos]

Bonjour,
Je viens de terminer la premiere salve de dévelopements,

Avec dans l'ordre :

• Augmentation du cache des GeoJSON par défaut à 30jours (8h à l'origine)
• Modification du moteur de rendu des appels API pour les listes (utilisation de django-rest-framework)
• Mise en place de la pagination des listes

La pagination des listes permet de n'appeler que les éléments visibles dans les listes de geotrek-admin lors de la visualisation, filtres et recherches.
Avant, tout devait être chargé dans le navigateur, et toutes ces opérations étaient réalisées dans le navigateur en javascript. Désormais, tout est éxecuté coté serveur, et les opérations de recherche / tri / filtres sont éxecutées en base de données et affichées page par page, ce qui permet d'augmenter sensiblement les performances sur cette partie.

Sur une base de 25 000 tronçons :

Avant, la liste chargée en entier, quand le cache est invalidé :

Avant, la liste chargée en entier, quand le cache est présent :

Désormais, sans cache, en chargeant juste la page affichée de la liste :

J'ai pasé 19j sur les 25j sur ces parties, qui comprend le socle qui sera utilisé par les prochaines étapes.

django-rest-framework est le socle commun qui permettra de générer les GeoJSON en utilisant les reprojections en base de données (avec ST_TRANSFORM - qui augmentera les performances encore en réalisant certaines opérations en une seule fois coté BDD, plutot qu'élément par élément en python). Cela permettra aussi de mettre en place le tuilage des GeoJSON dans une prochaine release.

Les 6 derniers jours seront donc consacrés à cette génération / optimisation des GeoJSON.

La pagination des listes sera disponible dans la prochaine version de Geotrek-admin, qui sera normalement la 2.82.0, disponible dans les prochains jours.

[submarcos]

Bonjour,
je viens de terminer la deuxième partie des dévelopements.
Concernant les geojson :

Sur une base de 25 000 tronçons :

Avant, la liste chargée en entier, quand le cache est invalidé :

Avant, la liste chargée en entier, quand le cache serveur est présent :

Avant, la liste chargée en entier, quand le cache navigateur est présent :

Désormais, sans cache, en chargeant juste la page affichée de la liste :

Désormais, quand le cache serveur est présent :

Désormais, quand le cache naviagteur est présent :

Le cache s'invalidant après chaque ajout / modification / suppression de tronçon, on constate qu'après une intervention sur ceux ci, le temps d'attente pour afficher une liste ou tracer un linéaire topologique est environ 16x plus rapide

Pour les prochaines étapes, je préconiserai :

• de filtrer les tronçons brouillons en JavaScript plutot que côté serveur (cache utilisé directement sans le regénérer une deuxième fois)
• de mettre à jour les bibliotheques JavaScript / Leaflet et d'optimiser le traitement des geojson (goulot d'étranglement à l'affichage)
• de mettre en place le système de tuilage

et à terme d'utiliser du routage coté backend ?

Rappel de ce qui a été fait :

• Optimisation de la génération de tous les GeoJSON
  • reprojection et simplification en 1x côté BDD avec postGIS (au lieu d'élément par élément en python)
  • compression gzip avec nginx (au lieu de python)
  • optimisation des requetes SQL au maximum
  • génération avec django-rest-framework (au lieu de django-geojson)

les GeoJSON de l'API v2 étaient déjà générés avec DRF et côté BDD, par contre la modification active la compression gzip qui n'était pas présente

[camillemonchicourt]

Super, une belle avancée de plus au niveau des performances. Merci.

[camillemonchicourt]

La partie 2 de l'amélioration des performances du chargement des GeoJSON a été intégrée dans la version 2.84.0.
En lien avec celle-ci, il est indiqué dans les notes de version :

• Que ceux dont Geotrek-admin est installé sur une version 18 d'Ubuntu (Bionic) doivent mettre à jour PostGIS en version 2.5, à la place de la 2.4 fournie par défaut sur cette version d'Ubuntu (voir la doc dédiée à la méthode pour le mettre à jour)
• Que le cache serveur doit être vidé après la mise à jour de Geotrek-admin en version 2.84.0
• Qu'il est conseillé de répercuter les améliorations du template de configuration NGINX pour que les fichiers JSON et GeoJSON soient compressés par NGINX (3d44447)

[Chatewgne]

De nouvelles évolutions sont à venir :

• Pour alléger le contenu HTML de la vue Liste lors de son ouverture, reporter le chargement des sélecteurs de filtrage (menus déroulants) au moment du clic d'ouverture du formulaire.
• Dans la vue détail, déplacer les Objets liés (sous les propriétés) dans un onglet dédié dont le contenu sera chargé uniquement lors de l'ouverture de l'onglet.

Ces deux mécanismes pourraient être approfondis dans un second temps : charger chaque sélecteur individuellement, chaque bloc d'objets liés individuellement (accordéons ?) mais cela n'est pas priorisé pour l'instant.