API V2 : Performances et utilisation par Geotrek-rando V3

[submarcos]

Après 2 jours d'analyse je partage le rapport concernant les performances de l'API V2 et de son utilisation par Geotrek-rando V3. Des pistes d'améliorations sont détaillées, qu'il faudra discuter, trancher et prioriser. Rapport

[submarcos]

https://github.com/GeotrekCE/Geotrek-rando-v3/issues/753

[AudreyRemy]

Bonjour @submarcos Dans le rapport, vous précisez que pour la suite de l'étude, vous attendez des retours sur les conclusions afin de déterminer le plan d'action. Qui doit vous faire ces retours ? En avez-vous eu ?

[camillemonchicourt]

Suite à cette analyse technique, une première phase d'évolutions va être réalisée par @submarcos :

• Mise en place de cache sur l'API V2 sur les principaux objets (détail d'une rando, liste des communes traversées par une rando...)
• Amélioration du mode de calcul des zones de sensibilité d'une rando

Cela ne permettra pas de mettre en cache sur tous les objets de l'API et de corriger tous les sujets identifiés sur les performances, mais de mettre en place une première vague d'améliorations significatives.

Il sera utile de compléter avec une autre série de développements.

[camillemonchicourt]

Les développements de ces premières améliorations des performances ont commencé ici : https://github.com/GeotrekCE/Geotrek-admin/pull/3306.

• Pour pouvoir invalider le cache des objets quand ceux-ci sont modifiés, il a fallu commencer par généraliser l'utilisation des champs date_insert et date_update dans toutes les tables secondaires où ces champs n'étaient pas présents.
• Pour renvoyer les zones sensibles à proximité d'une rando on utilise désormais un ST_Intersects avec les géométries des buffers des zones sensibles (stockées dans le nouveau champs sensitivity_sensitivearea.geom_buffered, calculé par un trigger) et non plus un ST_DWithin
• Début de mise en place de cache sur les routes de détail des objets

[submarcos]

Pour faire suite à ce ticket, et en complément des problèmes rencontrés avec les zones sensibles, il semblerait que l'usage de dwithin sur les filtres ?near_xxx impactent une majorité des endpoints de l'API. Plus il y a d'éléments dans la table à filtrer (comme les signalétiques par exemple) et plus la géométrie de l'élément est complexe (itinérance) et plus le calcul en BDD et la réponse API est longue (ex : /api/v2/signage/?near_trek=xxxx où xxxx est l'id d'une itinérance)

En effet l'usage de requêtes géographiques complexes ne semble pas viable pour une grande complexité de données pour un usage dans l'API. Dans l'interface geotrek-admin, les signalétiques reliées à un itinéraire utilise leur lien topologique, qui est écrit en BDD et ne necessite donc pas de calcul.

Il faut réfléchir à une solution, soit utiliser le lien topologique (avec les problématiques connues, à savoir un ponctuel qui est associé avec un seul tronçon sauf cas particulier des croisements, et le fait qu'une instance sans segmentation dynamique ne bénéficiera pas des améliorations) soit utiliser une table attributaire ou les éléments proches seraient calculées et stockés en amont pour améliorer les performances lors de leur consultation / filtrage (données et triggers SQL à mettre en place)