1. Celery vs rq

2. Points communs
• 2 gestionnaires de files d’attente
• En python

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

8. Utilisation de Celery
• Tuning du daemon prend du temps

9. Utilisation de Celery
• Pas de priorisation des tâches

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.

14. Questions

15. Personnal branling
• @nautilebleu
• @greenbureaufr