3. Celery en quelques mots
• Au départ une application django
• Devenu depuis un projet autonome
• Mais il peut toujours fonctionner de concert
avec django
4. Celery en quelques mots
• Distribué :
– un broker va recevoir les demandes de traitement
– des workers vont pouvoir les traiter
– les workers ne sont pas forcément sur le même
servery
5. Celery en quelques mots
• Projet déjà ancien, mais qui évolue beaucoup
– La politique de stabilité est très claire et la
déprécation d’une fonction intervient longtemps
avant sa suppression
• Très (trop ?) riche
6. rq en quelques mots
• Une alternative light à Celery
– Pas besoin de différents types de tâches
– Pas besoin de différents backends pour le broker
rq = Redis Queue
– Pas besoin de webhooks
7. Utilisation de Celery
• Doc complète et prise en main assez facile
– Malgré tout, il est souvent difficile de trouver
certaines infos
– On fait donc parfois des mauvais choix parfois
pénalisants pour la suite
10. Utilisation de Celery
• Monitoring : indispensable en asynchrone
– dj-celery si vous utilisez celery avec django
• 2 autres daemons à activer
• activation des évènements au niveau des daemons
surveillés
– Si le broker est RabbitMQ: plugin d’admin
11. Utilisation de rq
• Doc minimaliste (mais il y a beaucoup moins à
dire)
• Pas de status du résultat
12. Utilisation de rq
• Pas distribué (pas de channel, ni d’exchange ni
de router)
• Plusieurs workers mais une tâche à la fois
13. Utilisation de rq
• Python only : pas de webhooks
• Il existe une interface d'administration, mais
pour Flask.
• Ne fonctionne que sous Unix.
