The Ultimate Guide to Choosing WordPress Pros and Cons
Current State of Asynchronous Processing in Ruby
1. The Current State of
Asynchronous
Processing in Ruby
Mathias Meyer, Peritor GmbH
2. self
• Software-Developer for Peritor GmbH in Berlin
• Code-Reviews, Scaling, Performance-Reviews
and -Tuning, Refactorings
• Maintainer: acts_as_solr, run_later, heaps of stuff
for Capistrano/Webistrano
22. Message Queues
• Publish/subscribe mechanism
• Usually require more than one new
component in your infrastructure
• Broker middleware
• Subscribers, message listeners
24. Pollers
• Polling a database for new jobs
• Simple and domain-specific
• Only one new component
• Usually requires more effort to make them
less prone to errors
25. Pollers
• Roll Your Own w/ or w/o daemons gem
• delayed_job - adds some infrastructure
• background_job
33. Schedulers
• cron, cron, cron (oh, and rake)
• rufus-scheduler
• BackgrounDRb
• Quartz with JRuby (if you’re into that sort of
thing)
• Roll Your Own
35. Playing with the Big Guys
• Nanite - Jack of all trades
• Uses RabbitMQ, Erlang-based messaging
server, AMQP implementation
• Distributes work across a network of
workers
36. Nanite
• A self-assembling fabric of Ruby daemons
• Uses mappers and agents
• Mappers route message requests
• Agents handle messages
53. Stalled Workers
• Workers stopped processing jobs
• Got stuck on an a particular task
• Choked on an error
54. Stalled Workers
• Monitor your workers and queues
• Build in error reporting, report exceptions like
in the rest of your code
• Make jobs repeatable
• Use Nanite (self-healing)