Le document traite de l'évolution du développement web, passant des pages aux plateformes, et souligne la nécessité de gérer les tâches asynchrones avec des gestionnaires de files d'attente, notamment en utilisant des outils comme Celery et RQ. Celery est présenté comme un framework riche en fonctionnalités, mais avec des limitations selon les backends choisis, tandis que RQ est plus simple et adapté pour des environnements comme Heroku. Le texte met également l'accent sur l'importance de surveiller les tâches exécutées, affirmant que la surveillance prend plus de temps que le développement lui-même.

2. intro 1/2
• Au début du web on faisait des pages
• Puis on s'est mis à faire des sites
• Maintenant on fait des plate-formes

3. intro 2/2
Désormais, le site web est une partie de l'infra…
… et bien souvent, c'est la partie emergée de
l'iceberg

4. En synchrone
• On est bézu baisé

5. En asynchrone
• monitorer la dispo de vos ressources CPU (=workers);
• lancer une tâche quand un worker se libère;
• surveiller si la tâche se termine (et si elle se termine
bien…);
• en cas de problème, réessayer ou alerter.
D’où le besoin pour un gestionnaire de file d'attentes =
Message Queue dans la langue de Shakespeare.

6. En Python
• Celery : la plus connue
• rq : alternative light
• bindings Python à ØMQ : construisez votre
propre gestionnaire !
• pleins d'autres projets (Mozilla en a mis
plusieurs en OSS)

7. Celery 1/3
• A commencé comme une app django
• Désormais autonome (mais toujours une intégration
avec django=dj-celery)
• Gros projet, énormément de fonctionnalités out-of-
box : c'est un framework à lui tout seul
• Nombreux backends (RabbitMQ, redis, Mongo,
MySQL…)

8. Celery 2/3
• Le gros pb : toutes les fonctionnalités ne sont pas dispo avec tous
les backends !!
• Choisir un backend, c'est éventuellement se couper de plein de
fonctionnalités…
• Le backend (RMQ) recommandé est loin d'être le plus efficace :
– Impossible de réessayer une tâche qui a plantée;
– Pas de gestion des priorités;
• Le code évolue beaucoup et vite : c'est bien mais ça peut vous
amener à réécrire pas mal de code juste pour suivre les
changements de Celery

9. Celery 3/3
Un framework:
• Comme tous les frameworks, requiert du temps
pour bien le maîtriser
• Bien lire la doc, notamment le tableau qui liste
les options dispo en fonction des backends
• Peut être arrivé un peu tôt.

10. rq
• Plus simple
• Doc minimaliste (mais il y a moins à dire)
• Redis est le broker
• Unix only
• Taillé pour Heroku et les services similaires

11. ØMQ
ØMG ! ØMG !! ØMG !!!

12. Do It Yourself
• Plus simple qu'on ne le croit !
• Tout est disponible dans Python avec gevent
et redis

13. Monitorer
• Attention aux features, mais c'est pas le plus
important.
• Coder c'est 25% du temps, le plus long, c'est
de monitorer !

14. Questions