Mise en cache de l'API

[thbar]

Après avoir fait:

• 3302

On voit qu'on a environ 70k requêtes d'API par mois en projeté.

J'ai observé que:

• les requêtes sont globalement bien lentes
• mais compliquées à retoucher pour le moment
• et plutôt sur une fréquence faible

Donc on va plutôt dans un premier temps travailler à mettre en cache de durée courte (type 60 secondes) sur les endpoints qu'AppSignal a permis d'identifier.

Ca n'améliorera pas la rapidité des réponses pour les utilisateurs actuels, mais ça nous protègera si l'usage se développe (protection du pool de connection base de données en particulier).

Je vais plancher là dessus, en m'inspirant de ce que j'avais mis en place ailleurs dans l'application, et peut-être en dégageant un behaviour Cache pour faciliter le travail dans les tests.

[thbar]

Si je trie par "lenteur décroissante" (et donc par potentiel de création d'ennuis sur le pool de base de données), ça donne ça, pour savoir où aller brancher le cache:

Je vois qu'on a grosso modo les contrôleurs et actions suivantes:

• TransportWeb.API.StatsController#quality - déjà en cache via render_features
• TransportWeb.API.StatsController#index - déjà en cache via render_features
• TransportWeb.API.StatsController#regions - déjà en cache via render_features
• TransportWeb.API.DatasetController#datasets - pas en cache
• TransportWeb.API.DatasetController#by_id - pas en cache
• TransportWeb.API.AomController#geojson - pas en cache mais throughput tout petit actuellement
• TransportWeb.API.GeoQueryController#index - déjà en cache (1 heure)

[thbar]

Une partie est en fait déjà en cache, je documenterai ça ici pour voir ce qui reste à faire.

[thbar]

L'essentiel est sous cache à présent, on peut clôturer et assurer la charge sans souci.

La suite du travail portera sur l'application web.