Development #50525
Permettre l'utilisation de uwsgi (en plus du serveur django)
0%
Description
Uwsgi utile pour tester les jobs (#48407, #50017), le serveur django restant utile pour aller taper du pdb etc.
Et parait-il qu'il y a aurait moyen de faire un truc intelligent qui tente d'abord le serveur uwsgi et qui se rabat su le serveur django si jamais je sais pas quoi, et que tout ceci marcherait encore plus facilement en utilisant systemd plutôt que supervisord.
Je laisse l'auteur de cette idée disruptive en expliquer les grandes lignes.
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Thomas Noël il y a environ 3 ans
Emmanuel Cazenave a écrit :
Et parait-il qu'il y a aurait moyen de faire un truc intelligent qui tente d'abord le serveur uwsgi et qui se rabat su le serveur django si jamais je sais pas quoi
Cf https://nginx.org/en/docs/http/ngx_http_upstream_module.html
En gros sans doute quelque chose de ce genre :
upstream combo { server 127.0.0.1:8034 weight=5; # par défaut, supervisor / runserver server unix:/socket/uwsgi backup; # mais si y'a pas, uwsgi } server { location / { proxy_pass http://combo; } }
Mis à jour par Emmanuel Cazenave il y a environ 3 ans
Et systemd c'était comme ça ? Il me semblait que tu avais une bonne raison, dont je ne me rappelle plus.
Mis à jour par Thomas Noël il y a environ 3 ans
Emmanuel Cazenave a écrit :
Et systemd c'était comme ça ? Il me semblait que tu avais une bonne raison, dont je ne me rappelle plus.
J'ai un peu regardé systemd-user et ça me semble pas si simple, on pourrait "juste" basculer en uwsgi dans un premier temps, en modifiant supervisorctl. Mais tout à coup je me demande si uwsgi sait faire du reload-automatique-quand-je-touche-un-fichier-py à la runserver, et j'en doute, or c'est quand même ça qui est super pratique avec runserver.
Peut-être que mon idée disruptive n'est pas si géniale.
Mis à jour par Emmanuel Cazenave il y a environ 3 ans
Thomas Noël a écrit :
Mais tout à coup je me demande si uwsgi sait faire du reload-automatique-quand-je-touche-un-fichier-py à la runserver, et j'en doute, or c'est quand même ça qui est super pratique avec runserver.
Ça me dérange pas, d'autant qu'on resterait sur du runserver par défaut, ce serait quand même bien d'avoir uwsgi sous la main prêt à l'emploi.
Mis à jour par Benjamin Dauvergne il y a environ 3 ans
Thomas Noël a écrit :
J'ai un peu regardé systemd-user et ça me semble pas si simple, on pourrait "juste" basculer en uwsgi dans un premier temps, en modifiant supervisorctl. Mais tout à coup je me demande si uwsgi sait faire du reload-automatique-quand-je-touche-un-fichier-py à la runserver, et j'en doute, or c'est quand même ça qui est super pratique avec runserver.
Ça existe, https://uwsgi-docs.readthedocs.io/en/latest/Options.html#py-auto-reload
Mis à jour par Emmanuel Cazenave il y a environ 3 ans
- Lié à Development #52221: uwsgi, spooler, connexion db ajouté
Mis à jour par Emmanuel Cazenave il y a presque 3 ans
- Fichier 0001-add-uwsgi-as-available-application-server-50525.patch 0001-add-uwsgi-as-available-application-server-50525.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Assigné à mis à Emmanuel Cazenave
- Patch proposed changé de Non à Oui
Voilà qui permet d'utiliser uwsgi, je n'en fais pas le serveur par défaut pour autant, laissons mûrir.
Pour passer de runserver à uwsgi, c'est par exemple pour combo :
supervisorctl stop combo supervisorctl start combo-uwsgi
Les deux service sont configurés pour écouter sur le même port, pas de cohabitation possible, mais du coup rien à changer cote nginx.
Dans les chose notables, je réutilise les uwsgi.ini inclus dans les sources, modulo quelques modifications (la socket, autoreload ...).
Aussi je tape un lien symbolique du uwsidecorators système dans le virtualenv, le uwsgidecorators de pypi est pas du tout à jour, et de toute façon ça sent les emmerdes de faire autrement.
Mis à jour par Emmanuel Cazenave il y a presque 3 ans
Emmanuel Cazenave a écrit :
Dans les chose notables, je réutilise les uwsgi.ini inclus dans les sources, modulo quelques modifications (la socket, autoreload ...).
J'oubliais le point important des cron uwsgi qui sont shootés. Je suis une peur frileux, ça pourra être revu, en attendant il y a déjà possibilité de surcharger la conf uwsgi dans des ~/.config/publik/settings/foo/settings.d/uwsgi-local.ini
pour les amateurs.
Mis à jour par Thomas Noël il y a presque 3 ans
Emmanuel Cazenave a écrit :
Emmanuel Cazenave a écrit :
Dans les chose notables, je réutilise les uwsgi.ini inclus dans les sources, modulo quelques modifications (la socket, autoreload ...).
J'oubliais le point important des cron uwsgi qui sont shootés. Je suis une peur frileux, ça pourra être revu, en attendant il y a déjà possibilité de surcharger la conf uwsgi dans des
~/.config/publik/settings/foo/settings.d/uwsgi-local.ini
pour les amateurs.
(rien à voir : si c'est toujours pour l'affaire de mails qui pourraient partir par erreur, je me disais l'autre jour qu'on pourrait intégrer https://docs.djangoproject.com/en/2.2/topics/email/#file-backend dans devinst ... mais d'abord voir comment gérer ça dans wcs ... encore un fil à tirer d'une pelote de laine)
Mis à jour par Frédéric Péters il y a presque 3 ans
Bout de pelote qu'on regarde sans tirer : #36977
Mis à jour par Thomas Noël il y a presque 3 ans
Frédéric Péters a écrit :
Bout de pelote qu'on regarde sans tirer : #36977
Ca me rappelait bien quelque chose, et je vais pas me relancer dans la bataille, mais sans doute que devinst a évolué depuis hein bon.
Bref, impeccable pour ce patch déjà Manu, et allons-y déjà sans les cron, on verra ensuite. Déjà les spooler c'est cool.
Je me dis qu'on pourrait quand même dès maintenant modifier les uwsgi.ini pour y être moins bourrins en lancement de workers :
- spooler-processes = 1 (au lieu de 3 par défaut, 1 suffirait en local mais avec 2 on peut voir les pépins de)
- processes = 5 (parce qu'on a mis 500 sur nos machines mais bon en local, bon)
- cheaper = 2 (nombre mini de workers)
- cheaper-initial = 2 (worker au démarrage)
- cheaper-step = 1 (on ajoute des workers un par un)
- cheaper-busyness-backlog-alert = 2 (workers en cas d'urgence)
- cheaper-busyness-backlog-step = 2 (workers en cas d'urgence)
- cheaper = 3
Et aussi, il doit manquer dans un coin la création des répertoires spooler, non ? (uwsgi ne le fait pas de lui même)
Dans la config de supervisor je n'ai pas compris le commentaire « ; Concurrency set to 1 because there is no lock around calls to hobo_notify », c'est peut-être juste une scorie de hobo-agent à supprimer ?
Aussi, plutôt mettre les cron en commentaire ? Genre avec
ansible.builtin.replace: path: "{{uwsgi_settings}}" regexp: '^(cron .*)$' replace: '#commented by devinst# \1'
Mis à jour par Emmanuel Cazenave il y a presque 3 ans
- Fichier 0001-add-uwsgi-as-available-application-server-50525.patch 0001-add-uwsgi-as-available-application-server-50525.patch ajouté
Thomas Noël a écrit :
Je me dis qu'on pourrait quand même dès maintenant modifier les uwsgi.ini pour y être moins bourrins en lancement de workers
On pourrait attendre de voir à l'usage ? C'est censé s'adapter à une faible charge, je suis partisan d'attendre une éventuelle constatation empirique que c'est chiant ce nombre de worker excessif au début avant de s'embêter à tout changer.
Et aussi, il doit manquer dans un coin la création des répertoires spooler, non ? (uwsgi ne le fait pas de lui même)
Fait, j'avais zappé.
Dans la config de supervisor je n'ai pas compris le commentaire « ; Concurrency set to 1 because there is no lock around calls to hobo_notify », c'est peut-être juste une scorie de hobo-agent à supprimer ?
Oui, supprimé.
Aussi, plutôt mettre les cron en commentaire ? Genre avec
Fait (avec une syntaxe légèrement différente parce la doc pointée concerne une version d'ansible trop récente par rapport à ce que l'on a dans debian). Et ça m'a donné l'idée de #53066.
Mis à jour par Thomas Noël il y a presque 3 ans
- Statut changé de Solution proposée à Solution validée
Emmanuel Cazenave a écrit :
Thomas Noël a écrit :
Je me dis qu'on pourrait quand même dès maintenant modifier les uwsgi.ini pour y être moins bourrins en lancement de workers
On pourrait attendre de voir à l'usage ? C'est censé s'adapter à une faible charge, je suis partisan d'attendre une éventuelle constatation empirique que c'est chiant ce nombre de worker excessif au début avant de s'embêter à tout changer.
On sera quand même sur 5 workers par brique au moins (cheaper = 5), ça va bouffer de la ram gratuitement. Bon après oui, on s'en fout, on a plein de RAM sur nos machines persos, on verra à l'usage ça me va très bien !
Mis à jour par Emmanuel Cazenave il y a presque 3 ans
- Statut changé de Solution validée à Solution déployée
commit 934cfff69dff3ea569cb547a017ac8b40dfdcc89 Author: Emmanuel Cazenave <ecazenave@entrouvert.com> Date: Wed Mar 31 16:22:35 2021 +0200 add uwsgi as available application server (#50525)
add uwsgi as available application server (#50525)