Page stat - des données ne sont pas affichées (erreur 500)

[AurelienC]

Des statistiques ne sont pas affichées sur la page stats, notamment : fraicheur et qualité des données.

L'inspecteur montre des erreurs 500 :

Lié à https://transport-data-gouv-fr.sentry.io/issues/3016768499/?project=6197733 ?

[vdegove]

C’est un problème de timeout de la requête entre le backend Elixir et la base de données.

DBConnection.ConnectionError

tcp recv (idle): closed (the connection was closed by the pool, possibly due to a timeout or because the pool has been terminated)

En rafraîchissant la page s’affiche :

Ça devrait pouvoir se régler avec plus de cache (attention ne pas confondre).

[vdegove]

Ma proposition de filou (@thbar) : remplir avec un job Oban régulièrement le cache via la fonction Cachex.put/4 de manière à ce que l’endpoint API lise toujours le contenu du cache sans jouer la requête SQL.

Disons le cache généré toutes les 15 minutes, et le délai ici mis à 30 minutes (comme il n’y a pas de valeur, on tombe sur le défaut de 60s) : https://github.com/etalab/transport-site/blob/master/apps/transport/lib/transport_web/api/controllers/stats_controller.ex#L260

C’est l’output de la fonction quality_features_query/0 (https://github.com/etalab/transport-site/blob/master/apps/transport/lib/transport_web/api/controllers/stats_controller.ex#L378) qui est à mettre sous la clef de cache api-stats-quality. Tant qu’à faire d’ailleurs, on pourrait faire ça pour tous les points d’API utilisés par cette page, et pas uniquement /api/stats/quality

[thbar]

C'est une bonne idée, ça avait déjà été envisagé en deuxième passe d'ailleurs lors de la mise en cache que tu as pointé, mais temporisé car pas nécessaire à ce moment là.

#quality et #index sont des "hot-spots" qu'on retrouve bien quand on trie par temps de réponse décroissant dans l'APM (menu Performance / Actions):

Notes importantes je pense:

• Sur ces deux actions, le délai me semble bien ; il faudra vérifier que ça ne peut pas créer de situations où la personne clique sur un lien, et il est invalide (je ne pense pas que ça sera le cas sur cet exemple mais il faut vérifier)
• Bien s'assurer qu'on peut vérifier avant / après au niveau de l'optimisation (mais ces deux urls sont monitorées dans AppSignal donc ça se verra bien)
• Attention, côté API (voir Dégradation performance site/API (suite à usage accru API) #4420) il faudra faire pareil sur l'index ; mais pas avec le même délai (plutôt toutes les 60 secondes)
• 🚨la requête (ou les) correspondante est juste beaucoup trop lente actuellement (13,7sec 90th percentile) : il faudra ou l'optimiser, ou a minima augmenter son time-out au moment de la query Ecto, sinon on aura le même souci (on peut même se retrouver dans une situation "absurde" où le job en cache échoue, et la requête au dessus se fait du coup quand même, ce qui augmente au global la charge du système)
• 🚨attention à éviter tout empilement de job dans le système (il faut un job unique etc) en particulier via du retry, sinon... on peut faire tomber tout le site (ou le worker dans ce cas) via une "exhaustion" du pool Ecto

Je propose de commencer plutôt côté stats vu que c'est cassé, et on fera un tour sur l'API semaine prochaine (mais c'est un vrai sujet aussi et l'usage va encore augmenter, car MobilityData par exemple va ajouter une intégration automatique).