Bug #1554
fermé
Requêtes sur les mesures à optimiser
Description
Lorsque la base est peuplée de beaucoup de mesures, alors la requête permettant de récupérer un JSON des mesures d'un paramètres est trop longue.
- Mesurer le temps dans la situation actuelle en ayant importé un grand nombre de mesures
- Investiguer côté PostgreSQL, à l'aide d'unre requête SELECT de référence
- Éliminer les points chauds de la requête par des index ou autres optimisations
- Mesurer le gain de performance ainsi obtenu
Dans les logs du serveur de production on peut voir cette ligne qui donne une indication sur la requête SELECT qui est passée :
D, [2017-02-14T15:46:42.037898 #18991] DEBUG -- : Measure Load (65996.8ms) SELECT "measures".* FROM "measures" WHERE "measures"."station_id" = $1 AND "measures"."parameter_id" = $2 ORDER BY "measures"."date" ASC [["station_id", 711], ["parameter_id", 169]]
Postgresql :
- utiliser la commande EXPLAIN : https://www.postgresql.org/docs/9.1/static/sql-explain.html
- ajouter des index : https://www.postgresql.org/docs/9.1/static/indexes.html
- évaluer le coût du tri
- voir si on peut obtenir directement une sortie JSON ? https://dockyard.com/blog/2014/05/27/avoid-rails-when-generating-json-responses-with-postgresql
https://www.postgresql.org/docs/9.3/static/functions-json.html
Mis à jour par Jonathan Schaeffer il y a plus de 7 ans
Postgresql :
- utiliser la commande EXPLAIN : https://www.postgresql.org/docs/9.1/static/sql-explain.html
- ajouter des index : https://www.postgresql.org/docs/9.1/static/indexes.html
- évaluer le coût du tri
- voir si on peut obtenir directement une sortie JSON ? https://dockyard.com/blog/2014/05/27/avoid-rails-when-generating-json-responses-with-postgresql
https://www.postgresql.org/docs/9.3/static/functions-json.html
Mis à jour par Jonathan Schaeffer il y a plus de 7 ans
En suivant cet exemple : http://www.highcharts.com/stock/demo/lazy-loading/
Préparer des mesures agrégées par heure et par jour.
Choisir le niveau d'agrégat en fonction de la taille de l'interval :
- interval > 2ans => par jour
- interval < 2 ans => par heure
- interval < 1 mois => non agrégé
Ex de requête SQL :
SELECT extract(epoch from date_trunc('day', date)) as day,avg(value),min(value),max(value) FROM measures WHERE (parameter_id = 2 AND station_id=1) GROUP BY day;
Pour ne pas instancier plein d'objets mesures inutiles, on peut demander à Postgres du JSON :
SELECT json_build_array(extract(epoch from date_trunc('day', date)),avg(value)) FROM measures WHERE (parameter_id = 2 AND station_id=1) GROUP BY extract(epoch from date_trunc('day', date));
Ensuite, dans le MeasuresController#highstock, accepter les intervales start et end, et appeler une fonction privée d'agregation pour obtenir le json bien formé.
Mis à jour par Jonathan Schaeffer il y a plus de 7 ans
- Statut changé de Nouveau à Fermé
- % réalisé changé de 0 à 100