Stratégie de cache
Le temps que nécessite ws-ppsd pour calculer un spectrogram (60s pour une année), me fait quand même refléchir sur l'opportunité d'un système de cache, voici quelques arguments :
Contexte :
- la génération de spectro peut être hyper longue (1 minute)
- ws-ppsd sera en particulier appelé par le portail (donc avec des dates fixes), l'utilisateur clique et l'appel au webservice se déclenche
- les NPZ utilisés pour générer les spectro changent régulièrement, mais on le webservice ne sait pas quand
Plus j'y pense, plus je me dis qu'un système de cache serait une bonne idée. Il faudrait :
- qu'il soit persistant (survive à l'application)
- qu'il puisse être invalidé pour un channel donné
- qu'il puisse aussi être invalidé dans le temps
Voilà un scénario possible :
Le webservice reçoit une requête query :
- Si réseau temporaire, alors on cherche si une image existe dans la plage de temps et on la renvoie
- Si réseau permanent :
- une image correspondant à la requête existe déjà ? On la renvoie (cache hit)
- sinon on calcule l'image puis on la sauve dans le cache
Invalidation du cache :
- Si l'intégration de métadonnées rend le NPZ dirty, alors on invalide tout les caches correspondant au channel (le prochain querry sur ce channel renverra une nouvelle image avec le commentaire de péremption des stats)
- Si le cache dépasse un volume donné, alors on invalide les cache correspondant à des plages de temps les plus petites (les requêtes les plus rapide à régénérer)
- Si on recalcule un NPZ, alors un invalide le cache du channel correspondant
De plus, pour améliorer les performances du système de cache, que pensez-vous de tronquer toutes les dates des requêtes à la journée ? Afin d'éviter de calculer trop de PPSD pour des requêtes qui modifient juste une micro-seconde ...
Avez-vous d'autres idées de stratégie de limitation ?
Pensez-vous qu'il faille implémenter ce cache et avez-vous des idées pour la mise en œuvre ?