Development #50891
dataviz: mettre à jour la liste des statistiques plus fréquemment
0%
Description
Actuellement c'est toutes les heures, ce qui peut faire long quand on commence à travailler dans bijoe en créant régulièrement de nouvelles visus.
Fichiers
Révisions associées
dataviz: improve queries on statistics list update (#50891)
misc: add uwsgi spooler (#50891)
dataviz: refresh statistics list more frequently using spooler (#50891)
Historique
Mis à jour par Valentin Deniaud il y a environ 3 ans
- Fichier 0001-dataviz-update-statistics-list-every-5-minutes-50892.patch 0001-dataviz-update-statistics-list-every-5-minutes-50892.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Déplacement du code de hourly() vers une commande, qu'on appelle toutes les 5 minutes via cron.
Mis à jour par Thomas Noël il y a environ 3 ans
Ca prend du temps ? Parce qu'en prod on a bientôt 100 instances bijoe. Pour que le cron soit acceptable chaque 5 minutes il faut qu'il tourne en moins d'une minute sur ce volume (avec une marge de sécurité).
Mis à jour par Valentin Deniaud il y a environ 3 ans
- Fichier 0001-dataviz-update-statistics-list-every-5-minutes-50892.patch 0001-dataviz-update-statistics-list-every-5-minutes-50892.patch ajouté
Thomas Noël a écrit :
Ca prend du temps ? Parce qu'en prod on a bientôt 100 instances bijoe. Pour que le cron soit acceptable chaque 5 minutes il faut qu'il tourne en moins d'une minute sur ce volume (avec une marge de sécurité).
Oui c'est censé être rapide, ça fait par tenant autant de requêtes qu'il y a de sources de stats, c'est à dire deux actuellement (bijoe et a2). En prod,
time sudo -u combo combo-manage tenant_command runscript update_available_statistics.py --all-tenant real 1m16,605s user 0m16,769s sys 0m1,744s
C'est bien autour d'une minute, à toi de me dire si ça passe ou pas. J'ai rajouté un timeout=5 sur le requests.get pour être plus safe.
Mis à jour par Thomas Noël il y a environ 3 ans
Discuté rapido au bureau : regarder si on ne pourrait pas plutôt faire juste un cache.
Mis à jour par Valentin Deniaud il y a environ 3 ans
- Fichier 0001-tests-count-dataviz-queries-50891.patch 0001-tests-count-dataviz-queries-50891.patch ajouté
- Fichier 0003-dataviz-reduce-queries-number-on-statistics-list-upd.patch 0003-dataviz-reduce-queries-number-on-statistics-list-upd.patch ajouté
- Fichier 0002-dataviz-load-statistics-list-dynamically-50891.patch 0002-dataviz-load-statistics-list-dynamically-50891.patch ajouté
Après benchmark en prod, la mise à jour de la liste des stats prend une demie seconde au pire sur les tenants les plus chargés, sinon en dessous de 0.1s. Donc faisable de mettre à jour en temps réel pendant le chargement de la page, sans cache.
Une difficulté, c'est que si plusieurs cellules graphe sont présentes sur la même page, il ne faut effectuer cette mise à jour qu'une fois (et pas pour toutes les cellules). Heureusement le problème s'était déjà posé ailleurs, donc utilisation du décorateur cache_during_request prévu à cet effet.
0001 pour montrer que 0002 fait quand même exploser le nombre de requêtes au chargement de la page, proportionnellement au nombre de stats (mais pas au nombre de cellules grâce au décorateur cité plus haut).
Ce qui justifie 0003, ne faire des requêtes que si nécessaire (et maximum 3 si django 2).
Mis à jour par Valentin Deniaud il y a environ 3 ans
Valentin Deniaud a écrit :
Après benchmark en prod, la mise à jour de la liste des stats prend une demie seconde au pire sur les tenants les plus chargés, sinon en dessous de 0.1s. Donc faisable de mettre à jour en temps réel pendant le chargement de la page, sans cache.
Pour GL, 0.75s (il y a une dizaine de bijoe à aller voir).
Mis à jour par Frédéric Péters il y a environ 3 ans
Après benchmark en prod, la mise à jour de la liste des stats prend une demie seconde au pire
C'est quand même long une demi-seconde, ou 0,75s à GL.
Mis à jour par Thomas Noël il y a environ 3 ans
Frédéric Péters a écrit :
Après benchmark en prod, la mise à jour de la liste des stats prend une demie seconde au pire
C'est quand même long une demi-seconde, ou 0,75s à GL.
J'ai l'impression que l'alternative est de passer par un cache mis à jour toutes les x minutes. C'est un délai qui va être, à mon avis, assez frustrant à l'usage ("j'ai mis une visu dans bijoe et je la vois pas dans combo ?" "oui, attendez x minutes").
Mis à jour par Frédéric Péters il y a environ 3 ans
Ça peut être un job lancé sur la consultation de la page, qui fera qu'à coup sûr ou presque, au reload, ça sera bon. Ça peut aussi être complexifié et ne procéder ainsi qu'en présence de n sources de statistiques. (là on est sur une demi-seconde avec authentic et bijoe, ça passera facilement à une seconde voire plus avec chrono et wcs).
Mis à jour par Valentin Deniaud il y a environ 3 ans
Frédéric Péters a écrit :
Ça peut être un job lancé sur la consultation de la page, qui fera qu'à coup sûr ou presque, au reload, ça sera bon.
Mais il n'y a pas de système de jobs dans combo. Il s'agirait d'utiliser le spooler uwsgi comme ce qui est fait dans #50723 côté chrono ?
Mis à jour par Valentin Deniaud il y a environ 3 ans
- Statut changé de Solution proposée à En cours
OK, je vais attendre que quelqu'un valide dans chrono avant de m'en inspirer.
Mis à jour par Valentin Deniaud il y a environ 3 ans
- Fichier 0002-dataviz-improve-queries-on-statistics-list-update-50.patch 0002-dataviz-improve-queries-on-statistics-list-update-50.patch ajouté
- Fichier 0001-dataviz-move-statistic-list-update-code-50891.patch 0001-dataviz-move-statistic-list-update-code-50891.patch ajouté
- Fichier 0004-dataviz-refresh-statistics-list-more-frequently-usin.patch 0004-dataviz-refresh-statistics-list-more-frequently-usin.patch ajouté
- Fichier 0003-misc-add-uwsgi-spooler-50891.patch 0003-misc-add-uwsgi-spooler-50891.patch ajouté
- Statut changé de En cours à Solution proposée
0002 : rescapé de mes précédents patches, c'est moins important maintenant mais toujours bon à prendre j'imagine
0003 : copié depuis chrono, full credit à Lauréline
0004 : un peu pareil
Pour lancer combo avec uwsgi,
COMBO_SETTINGS_FILE=/home/$USER/.config/publik/settings/combo/settings.py uwsgi --chdir . --module=combo.wsgi:application --env DJANGO_SETTINGS_MODULE=combo.settings --master --process 3 --pidfile=/tmp/project-master.pid --http=127.0.0.1:8004 --spooler-python-import=combo.utils.spooler --spooler /var/lib/combo/spooler/
Mis à jour par Frédéric Péters il y a environ 3 ans
- Statut changé de Solution proposée à Solution validée
Mis à jour par Valentin Deniaud il y a environ 3 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit e7670e0ab1fa60de69392de687b515097387aed9 Author: Valentin Deniaud <vdeniaud@entrouvert.com> Date: Wed Feb 17 11:37:13 2021 +0100 dataviz: refresh statistics list more frequently using spooler (#50891) commit a6f2a755e1ccf7499636615e6e35ea66cd0f06ab Author: Valentin Deniaud <vdeniaud@entrouvert.com> Date: Wed Feb 17 10:54:20 2021 +0100 misc: add uwsgi spooler (#50891) commit 38ba201a5f6b16365f178f387da31eba7927acd2 Author: Valentin Deniaud <vdeniaud@entrouvert.com> Date: Thu Feb 11 11:59:00 2021 +0100 dataviz: improve queries on statistics list update (#50891) commit 452e671c7b4577c2020e6fd9930a72b0d5464564 Author: Valentin Deniaud <vdeniaud@entrouvert.com> Date: Wed Feb 17 10:39:02 2021 +0100 dataviz: move statistic list update code (#50891)
Mis à jour par Frédéric Péters il y a environ 3 ans
- Statut changé de Résolu (à déployer) à Solution déployée
dataviz: move statistic list update code (#50891)