Celery vs rq
Points communs• 2 gestionnaires de files d’attente• En python
Celery en quelques mots• Au départ une application django• Devenu depuis un projet autonome• Mais il peut toujours fonctio...
Celery en quelques mots• Distribué :  – un broker va recevoir les demandes de traitement  – des workers vont pouvoir les t...
Celery en quelques mots• Projet déjà ancien, mais qui évolue beaucoup  – La politique de stabilité est très claire et la  ...
rq en quelques mots• Une alternative light à Celery  – Pas besoin de différents types de tâches  – Pas besoin de différent...
Utilisation de Celery• Doc complète et prise en main assez facile  – Malgré tout, il est souvent difficile de trouver    c...
Utilisation de Celery• Tuning du daemon prend du temps
Utilisation de Celery• Pas de priorisation des tâches
Utilisation de Celery• Monitoring : indispensable en asynchrone  – dj-celery si vous utilisez celery avec django     • 2 a...
Utilisation de rq• Doc minimaliste (mais il y a beaucoup moins à  dire)• Pas de status du résultat
Utilisation de rq• Pas distribué (pas de channel, ni d’exchange ni  de router)• Plusieurs workers mais une tâche à la fois
Utilisation de rq• Python only : pas de webhooks• Il existe une interface dadministration, mais  pour Flask.• Ne fonctionn...
Questions
Personnal branling• @nautilebleu• @greenbureaufr
Prochain SlideShare
Chargement dans…5
×

Meetup django-2012-06-14

1 160 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 160
Sur SlideShare
0
Issues des intégrations
0
Intégrations
515
Actions
Partages
0
Téléchargements
6
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Meetup django-2012-06-14

  1. 1. Celery vs rq
  2. 2. Points communs• 2 gestionnaires de files d’attente• En python
  3. 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. 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. 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. 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. 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. 8. Utilisation de Celery• Tuning du daemon prend du temps
  9. 9. Utilisation de Celery• Pas de priorisation des tâches
  10. 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. 11. Utilisation de rq• Doc minimaliste (mais il y a beaucoup moins à dire)• Pas de status du résultat
  12. 12. Utilisation de rq• Pas distribué (pas de channel, ni d’exchange ni de router)• Plusieurs workers mais une tâche à la fois
  13. 13. Utilisation de rq• Python only : pas de webhooks• Il existe une interface dadministration, mais pour Flask.• Ne fonctionne que sous Unix.
  14. 14. Questions
  15. 15. Personnal branling• @nautilebleu• @greenbureaufr

×