search

GeotrekCE / Geotrek-admin

Paths management for National Parks and Tourism organizations
https://geotrek.fr
BSD 2-Clause "Simplified" License
131 stars 75 forks source link

Performances de chargement et de navigation #2967

Open camillemonchicourt opened 2 years ago

camillemonchicourt commented 2 years ago

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 : https://github.com/GeotrekCE/Geotrek-admin/pull/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 commented 2 years ago

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

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

camillemonchicourt commented 2 years ago

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 commented 2 years ago

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

Avec dans l'ordre :

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é : Capture d’écran du 2022-04-27 09-31-45

Avant, la liste chargée en entier, quand le cache est présent : Capture d’écran du 2022-04-27 09-37-15

Désormais, sans cache, en chargeant juste la page affichée de la liste : Capture d’écran du 2022-04-27 09-33-06

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 commented 2 years ago

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é : path_sans_cache

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

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

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

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

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

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 :

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

Rappel de ce qui a été fait :

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 commented 2 years ago

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

camillemonchicourt commented 2 years ago

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 :