Meetup django-2012-06-14
- 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