Development #9932
Cache paresseux de package_version
0%
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Benjamin Dauvergne il y a environ 8 ans
- Fichier 0001-cache-package-version-lazily-fixes-9932.patch 0001-cache-package-version-lazily-fixes-9932.patch ajouté
- Patch proposed changé de Non à Oui
Mis à jour par Benjamin Dauvergne il y a environ 8 ans
- Lié à Development #9821: Accélérer le traitement des notifications ajouté
Mis à jour par Frédéric Péters il y a environ 8 ans
En fait ça n'a pas été fait comme ça parce qu'on ne veut pas non plus pénaliser la première requête. Ce qu'il faudrait c'est du code exécuté au démarrage mais pas pour les commandes de management (et j'écris ça sans être trop sûr de la possibilité, évidemment).
Mis à jour par Frédéric Péters il y a environ 8 ans
À réfléchir ici je me dis que ce code (ou en tout cas l'appel au code de mise en cache des versions) pourrait se faire dans le wsgi.py. Non ?
Mis à jour par Benjamin Dauvergne il y a environ 8 ans
Frédéric Péters a écrit :
En fait ça n'a pas été fait comme ça parce qu'on ne veut pas non plus pénaliser la première requête. Ce qu'il faudrait c'est du code exécuté au démarrage mais pas pour les commandes de management (et j'écris ça sans être trop sûr de la possibilité, évidemment).
Tu dis toi même que ça ne prend qu'1s, c'est quoi l'intérêt de gagner cette seconde sur la première requête après le lancement d'1 worker gunicorn ?
Mis à jour par Benjamin Dauvergne il y a environ 8 ans
- Fichier 0001-cache-package-version-lazily-fixes-9932.patch 0001-cache-package-version-lazily-fixes-9932.patch ajouté
Frédéric Péters a écrit :
À réfléchir ici je me dis que ce code (ou en tout cas l'appel au code de mise en cache des versions) pourrait se faire dans le wsgi.py. Non ?
Mis à jour par Benjamin Dauvergne il y a environ 8 ans
- Fichier 0001-cache-package-version-lazily-fixes-9932.patch 0001-cache-package-version-lazily-fixes-9932.patch ajouté
Erreur self -> cls
Mis à jour par Frédéric Péters il y a environ 8 ans
Tant qu'à pouvoir éviter le risque d'une requête lente à un client, je préfère.
Mis à jour par Benjamin Dauvergne il y a environ 8 ans
- Fichier 0001-cache-package-version-lazily-fixes-9932.patch 0001-cache-package-version-lazily-fixes-9932.patch ajouté
Le dernier patch n'était pas le bon.
Mis à jour par Frédéric Péters il y a plus de 7 ans
- Fichier 0001-misc-lazy-load-package-versions-9932.patch 0001-misc-lazy-load-package-versions-9932.patch ajouté
J'ai réfléchi à nouveau à ça (suite à #14616) et ma conclusion du jour c'est qu'on peut en fait avoir un cache paresseux pour toutes les applications sauf combo (où les informations de versions sont utilisées pour toutes les pages via statics_hash); et donc, ici, solution simple. Et dans combo un hack pour charger dès le début les versions.
Mis à jour par Frédéric Péters il y a plus de 7 ans
- Lié à Development #14621: ne pas se contenter du cache paresseux des versions ajouté
Mis à jour par Frédéric Péters il y a plus de 7 ans
En fait ça ne suffit pas parce que template_vars est chargé par toutes les applications au moment des requêtes.
Mis à jour par Frédéric Péters il y a plus de 7 ans
- Fichier 0001-misc-isolate-statics_hash-in-its-own-context-process.patch 0001-misc-isolate-statics_hash-in-its-own-context-process.patch ajouté
Déplacement du statics_hash dans son propre context processor, qui sera utilisé uniquement par combo.
Mis à jour par Frédéric Péters il y a plus de 7 ans
- Statut changé de Nouveau à Résolu (à déployer)
commit 35bfbd91db42fe34bdf4ef14fff50e8f55e43158
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Mon Jan 16 13:49:34 2017 +0100
misc: isolate statics_hash in its own context processor (#9932)
The benefit is to delay loading packages versions until they are
required.
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Résolu (à déployer) à Solution déployée
misc: isolate statics_hash in its own context processor (#9932)
The benefit is to delay loading packages versions until they are
required.