You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
L'intégration de symfony/messenger dans le role lephare/ansible-deploy me semble liée au transport Doctrine alors qu'on devrait tenir compte d'autre type de Transport (RabbitMQ par exemple).
Aujourd'hui crontab est utilisé pour lancer les workers. Je comprends que ce soit "good enough" pour la plupart des cas , mais nous devrions avoir des alternatives possibles, notamment ne pas utiliser crontab/Doctrine et préférer avoir la situation suivante:
utiliser Systemd en process manager pour s'assurer que nos workers tournent
utiliser --memory-limit=128M ou --time-limit=3600 en option du messenger:consume afin d'éviter les problèmes de mémoire. Systemd se charge de créer un nouveau process dans ce cas.
lancer la commande messenger:stop-workers au déploiement et pas forcément au before_doctrine
Aussi, je trouve dommage d'utiliser crontab car
on impose un delta de temps d'office au traitement asynchrone d'une tâche. Par exemple, si je configure un worker pour être lancé toutes les 7 minutes et que le worker plante au bout d'une minute, je devrais attendre le nextRun.
on se limite à 1 worker par symfony_messenger_queues alors que Systemd peut lancer plusieurs workers.
L'intégration de symfony/messenger dans le role lephare/ansible-deploy me semble liée au transport Doctrine alors qu'on devrait tenir compte d'autre type de Transport (RabbitMQ par exemple).
J'imagine que tu fait reference au setup-transport, effectivement doctrine nécessite cette étape mais d'autres transports peuvent l'implementer un jour (et probablement RabbitMQ pourrait faire partie de ceux là). Si tu utilises RabbitMQ ça fonctionne bien également.
Aujourd'hui crontab est utilisé pour lancer les workers. Je comprends que ce soit "good enough" pour la plupart des cas , mais nous devrions avoir des alternatives possibles, notamment ne pas utiliser crontab/Doctrine [...]
Crontab faisait partie des pré-requis et les hébergeurs nous fournissent généralement une implémentation satisfaisante. Nos experiences avec "supervisord", "systemd" et "pm2" n'étaient pas aussi fiable.
Aussi, je trouve dommage d'utiliser crontab car
on impose un delta de temps d'office au traitement asynchrone d'une tâche. Par exemple, si je configure un worker pour être lancé toutes les 7 minutes et que le worker plante au bout d'une minute, je devrais attendre le nextRun.
Il s'agissait d'un tradeoff acceptable, un traitement asynchrone par définition n'est pas prioritaire. si ce traitement nécessite plus d'attention, tu peux mettre en place un healthcheck qui t'alertes qu'il tombe et / ou simplement réduire la durée d'execution en contre partie des performances.
on se limite à 1 worker par symfony_messenger_queues alors que Systemd peut lancer plusieurs workers.
Pour résumé, a mon avis, cette tâche remplie tout ce qu'on lui demande sans avoir besoin d'intervention de l’hébergeur. Si l’hébergeur propose une autre solution je pense qu'il est préférable de créer une tache custom dans ton projet et de désactiver celle-ci.
TLDR;
L'intégration de symfony/messenger dans le role lephare/ansible-deploy me semble liée au transport Doctrine alors qu'on devrait tenir compte d'autre type de Transport (RabbitMQ par exemple).
Aujourd'hui crontab est utilisé pour lancer les workers. Je comprends que ce soit "good enough" pour la plupart des cas , mais nous devrions avoir des alternatives possibles, notamment ne pas utiliser crontab/Doctrine et préférer avoir la situation suivante:
--memory-limit=128M
ou--time-limit=3600
en option dumessenger:consume
afin d'éviter les problèmes de mémoire. Systemd se charge de créer un nouveau process dans ce cas.messenger:stop-workers
au déploiement et pas forcément au before_doctrineAussi, je trouve dommage d'utiliser crontab car
symfony_messenger_queues
alors que Systemd peut lancer plusieurs workers.Comment ça marche ajd ?
https://github.com/le-phare/ansible-deploy/blob/master/config/steps/symfony/messenger/after_symlink.yml
Cette tâche est exécutée lors que la variable
symfony_messenger_enabled
est true.https://github.com/le-phare/ansible-deploy/blob/master/config/steps/symfony/messenger/before_doctrine.yml
Suggestions
symfony_messenger_enable
n'a a priori rien à voir avec la tâche symfony_messenger_enableRéférences:
The text was updated successfully, but these errors were encountered: