Developers hankering for more performance from their Rack and Rails applications are using Ruby 1.9 fibers and event-based EventMachine-driven libraries as a way to boost the performance of their applications - in opposition to scaling by merely running multiple processes or using threads.
It's no secret that thread-based development can be Hard™, even if you didn't have to deal with Ruby quirks like autoloading not working properly and the GIL (Global Interpreter Lock). Luckily, Ruby 1.9 provides fibers, light-weight "execution units" that are manually scheduled by their parent application.
Back in April, Mike Perham introduced Phat, an asynchronous Rails 2.3.5 app running on Ruby 1.9 and supporting "many concurrent requests in a single Ruby process." In his explanation, he referred back to Scalable Ruby Processing with EventMachine, a talk he gave at Austin On Rails that's worth checking out.
Event-based database drivers are used to keep database queries asynchronous (this, however, is not a new concept) so that execution can be switched deftly between multiple fibers each serving a separate Web request by the rack-fiber_pool middleware component. Ilya Grigorik's EM-Synchrony can then be used to make a collection of common EventMachine clients fiber-aware (for using Memcached, MongoDB, Beanstalk, and more). All of this works with any Rack app, not just in Rails.
This week, Aaron Gough has written an article called Improving application throughput 9x with asynchronous responses in Rails 3 that covers the concepts at a higher level and demonstrates how he ported an existing Rails app to use the concepts outlined above. In doing so, he increased his requests per second from 5.46 to 52.