Posted by Jon
on Tuesday, June 03
As promised, here are the slides from my RailsConf talk on Asynchronous Processing. The slides don’t always make sense without the context, so I’ve added a few labels here and there. If something doesn’t make sense, feel free to ask about it.
Summary: if your web app has any sort of complexity, you’ll likely have some operations that are best processed asynchronously. In particular, any operation that takes a long time, is resource-intensive, or isn’t naturally triggered by http or by a human is a good candidate for asynchronous processing. You can build your own solution, but before you do, check out Bj for most uses, workling/starling for high performance or scalability, Amazon web services for distributed processing, and plain old cron for basic cases.
I also gave a lightning talk called “How not to present at RailsConf in 14 easy steps” – it’s just 2-3 minutes long, so I think I’ll turn it into a screencast. Look for that later this week.
Posted by Jon
on Monday, February 25
It looks like I will be speaking at RailsConf again. This time, I’ll be discussing asynchronous processing.
If you’ve worked on a Rails app that strays beyond basic CRUD, you’ve probably had to think about running some actions in the background – that is, outside of the HTTP request/response cycle. I’ve had to worry about this on quite a few projects, and contributed a recipe to the forthcoming Advanced Rails Recipes book. The recipe discussed how to package a Ruby script as a daemon, which is a simple and powerful approach to background processing. But there are quite a few others, including (but not limited to): AP4R, cron, starling, workling, beanstalk, backgroundrb, spawn, background_fu, and Amazon SQS. And I’ve left out quite a few.
So as I prepare for the conference, I’d love your feedback. What options have you tried? What has worked well or worked poorly? What would you like to see at the conference?
