Background jobs

Background jobs - Ruby/Rails - Programmation

Marsh Posté le 05-07-2009 à 13:51:43    

Plutôt que de tout mélanger avec le topic blabla rails, je fais un fork ici:
 

  • backgroundrb: Les tâches peuvent être sauvées dans la BDD. peut gérer les tâches à la place de cron. C'est le plus avancé, mais le plus lourd.
  • starling (+workling) : dév par Tweeter initialement mais ils ne s'en servent plus car trop lent (après c'est le volume de tweeter...), ils ont migré vers un système écrit en scala je crois. Système de gestion des tâches générique.
  • workling: plugin rails pour faciliter l'intégration de starling.
  • whenever: permet d'écrire des tâches cron avec du code ruby plus lisible.
  • backgroundjob: simple à installer avec persistence en BDD, mais il effectue trop de requêtes sql à mon goût, c'est peut-être configurable?
  • system "... &": c'est du ruby pur, par contre avec Rails ça ne marche pas correctement à cause d'ActiveRecord qui bloque une connection, donc le process parent peut rester bloqué.
  • spawn: c'est comme system "... &" sauf qu'une connection AR est créé et donc le process parent est totalement libéré. Ne gère pas les background jobs de manière séquentielle (sauf si utilisé avec workling?), ne peut pas être délégué sur d'autres serveurs.
  • background-fu: il check toutes les 5s la DB, pour moi c'est chiant mais ça permet de monitorer l'avançement des jobs (est-ce vraiment nécessaire?)
  • ap4r:
  • beanstalkd: beanstalkd is a fast, distributed, in-memory workqueue service. Pas initialement destiné à Rails (utiliser async_observer pour ça). Utilisé par reevoo. Non persistent.
  • async_observer: plugin supplémentaire à beanstalkd qui permet d'intégrer facilement beanstalkd à une appli Rails.
  • SQS: service d'Amazon pour gérer les tâches, il faut lui rajouter un runner.
  • rudeQ: persistent en BDD. Voir le lien rubyinside où ils disent que rudeQ et tout système persistent en BDD est lent (mais peut être tout à fait suffisant). C'est simplement un équivalent à Starling mais qui utilise la BDD, donc à utiliser avec Workling par exemple.
  • run_later: équivalent à spawn.
  • delayed_job: persistent en BDD, extrait de Shopify  [:benou_miam] On met une date de démarrage de la tâche  et y'a un daemon qui check toutes les 5s la BDD pour lancer les jobs, à-la cron quoi.
  • nanite: pour des très gros projets, voir [8]


Resources:
[1] http://www.scribd.com/doc/6134982/ [...] esentation
[2] http://www.scribd.com/doc/2589535/ [...] s-in-Rails
[3] http://transfs.com/devblog/2009/04 [...] -starling/
[4] http://railspikes.com/2008/6/3/asy [...] sconf-2008
[5] http://www.rubyinside.com/starling [...] s-958.html
[6] http://www.reevoo.com/labs/beanstalk-messaging/
[7] http://devver.net/blog/2008/06/rub [...] -shootout/
[8] http://www.slideshare.net/mattmatt [...] el=1215323


Message édité par igarimasho le 30-08-2009 à 16:00:25
Reply

Marsh Posté le 05-07-2009 à 13:51:43   

Reply

Marsh Posté le 05-07-2009 à 18:45:16    

Finalement j'utilise backgroundjob, parce que c'est vraiment le moins prise de tête.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed