Developers who want their Rack and Rails applications perform better and faster scale their applications by running multiple processes or using threads or… they are just using Ruby 1.9 fibers and event-based EventMachine-driven libraries. The idea behind this is rather simple and continuations have been a part of the Ruby API for a long time, though for variety of reasons it was not reliable enough to consider it for Ruby and Ruby on Rails production. However, with the production versions of Ruby 1.9 released, continuations – currently referenced as Fibers certainly deserve a second look.

For those who are not very familiar with the topic, Fibers, unlike functions which have defined entry point and exit point, can yield many times over, which means the execution of a Fiber can be suspended and then resumed from the same point on demand.

This leads to possibility to turn an asynchronous library into what looks like a synchronous API for use in Ruby on Rails development, without losing the advantage of IO-scheduling of the asynchronous execution!

If utilizing more CPU cores in not the option for your Ruby on Rails application then you should improve your application throughput with asynchronous responses (utilizing Fibers). You will easily find tutorials in the Net for Rails 2.X and Rails 3 applications.

But if you’re looking for uncompromised performance then think about such scenario: running X threads, where X corresponds to number of cores of your machine, and optimize the number of Fibers (Y) which can run within each thread. This way, your Ruby on Rails application can utilize all the available cores, and in the same time take advantage of the IO scheduling model.
Good luck with improving your Ruby on Rails application performance.