Feat: add cache for species, organism and area sheets

[jpm-cbna]

Use Flask-Cache for main pages.

[camillemonchicourt]

Je ne suis pas certain de ce que cela permet et implique ?
Cela met en cache quoi ?
Si les données évoluent, le cache persiste malgré tout un certain temps ?

[jpm-cbna]

C'est l'activation pour de nouvelles routes du cache Flask-Caching déjà en place dans l'Atlas pour les routes /main_stats et /rank_stats.

Dans cette PR, il est activé pour les routes des fiches Espèces, Territoire et Organisme. Cela permet d'accélérer le rendu en évitant l'exécution de requêtes SQL.

Un redémarrage du service geonature-altas supprime le cache et le paramètre CACHE_TIMEOUT (existant également) permet de renouveler automatiquement le cache s'il n'y a pas de redémarrage (par défaut toutes les heures).

[gildeluermoz]

A priori il n'y a pas de raison de vider le cache tant que refresh_materialized_view_data() n'a pas été lancé.
Est-ce qu'il y aurait moyen de le mettre en cron ou de le synchroniser avec l'exécution de refresh_materialized_view_data() ?

[jpm-cbna]

A priori il n'y a pas de raison de vider le cache tant que refresh_materialized_view_data() n'a pas été lancé. Est-ce qu'il y aurait moyen de le mettre en cron ou de le synchroniser avec l'exécution de refresh_materialized_view_data() ?

Je ne pense pas qu'il soit possible de relier le redémarrage d'un service Systemctl à l'exécution d'une fonction PSQL...

On pourrait seulement proposer un script Bash de refresh des VM qui se chargerait de lancer la fonction Postgresql. Dans ce cas là, oui, cela serait possible et peut être plus simple pour l'utilisateur...

[TheoLechemia]

Dans tous les cas il faudrait un paramètre pour que la durée du cache puisse s'adapter aux instances qui raffraichissent leur données toutes les heures, jours, semaines

[camillemonchicourt]

Et il faut s'assurer qu'on ne sature pas l'espace disque du serveur avec du cache ?

[jpm-cbna]

Dans tous les cas il faudrait un paramètre pour que la durée du cache puisse s'adapter aux instances qui raffraichissent leur données toutes les heures, jours, semaines

Tu parles d'un paramètre pour faire quoi exactement ? Est ce que le paramètre CACHE_TIMEOUT n'est pas suffisant ?

[TheoLechemia]

Ok oui, j'avais plus souvenir de ce paramètre. Du coup il faudrait baisser le 3600. Comme je disais, le cas le plus courant c'est quand meme d'avoir des données qui se raffraichisse à un pas de temps plutot rapide. Avec ce 3600, le cache va completement casser le raffraichissement

[gildeluermoz]

Complexe effectivement. Le rafraichissement du cache se faisant aléatoirement, par ex lors d'un restart du service, on ne peut pas le caler en terme de durée avec la synchronisation des bases.
On ne peut pas mettre un cache permanent (qui ne se vide qui si on le fait manuellement) et proposer 2 tâches cron ?

• une pour synchroniser les bases
• une pour vider le cache via une commande sh

[jpm-cbna]

Le mécanisme de cache s'appuie totalement sur Flask-Caching avec seulement les paramètres CACHE_TYPE à SimpleCache (=> cache en mémoire vive) et le CACHE_DEFAULT_TIMEOUT fixé par le paramètre CACHE_TIMEOUT de l'Atlas (par défaut 3600 seconde soit 1 heure).

Le mécanisme de cache doit rester simple. Il faut le voir comme une mécanique qui allège la charge du serveur de base de données. Par défaut, 500 entrées maximum sont stockés en mémoire avant qu'il ne supprime la plus ancienne pour la remplacer par une nouvelle.
Si on veut le réinitialiser tout le cache un redémarrage du service Systemctl de l'Atlas suffit...

Ceci dit, après discussion avec Théo, nous proposons de le modifier pour pouvoir passer à Flask-Caching tous les paramètres définit dans le fichier de config.py de l'Atlas commençant par CACHE_. De cette façon, nous pourrons profiter de toutes les options proposées : https://flask-caching.readthedocs.io/en/latest/#configuring-flask-caching

[TheoLechemia]

Comme discuté avec @jpm-cbna je trouve le mécanisme interessant.
Je me dis que pour être cohérent il faudrait le meme aussi sur les API, pour pas avoir la moitié de la page qui est caché et l'autre non. ça peut être un peu trompeur quand on met à jour des attributs par ex, qu'on voir que les attributs n'apparaissent pas encore alors qu'il y a des données toutes fraiches
Il faudrait aussi faire un peu de doc pour expliquer tout ça (ne pas mettre un un paramètre de cache > au raffraicissement des VM par exemple)