FAQ

Why should I use girl_friday versus any other queueing or asynchronous task system (e.g. Resque, DJ, etc)?

Two reasons: efficiency and simplicity. girl_friday is designed to run in-process with your Rails/Sinatra/Rack webapp. This makes it much more efficient from a memory perspective than a process-based system like Resque. If you have five Resque worker processes, each might take 100MB for a total of 500MB. girl_friday just reuses most of the same code as your application so you don't need that extra memory. Because it's in-process, you don't need to monitor it or deploy it. If your webapp is up and responding, so is girl_friday.

Keep in mind that girl_friday is designed to solve the problem of background tasks, not network messaging. If you have a complex system with different moving parts, it is entirely reasonable to use a message queueing system to coordinate between the parts. girl_friday is not appropriate in this case, this is exactly what RabbitMQ, ActiveMQ and other mature MQ solutions are designed to solve.

What app server should I use with girl_friday?

girl_friday works best in a Thread-friendly environment. Event-based systems like EventMachine are not thread-friendly so I don't recommend Thin or Goliath. If you are using JRuby, I would suggest looking at TorqueBox or Trinidad. If you are using Rubinius or Ruby 1.9.2, I would suggest Unicorn or Rainbows! with the ThreadPool concurrency strategy. Same goes for running girl_friday on Heroku's Cedar stack.