Personal Bytes

Where did we come from?

A lot has happened in the last year regarding Ruby on Rails. It evolved from version 1.0 through 1.2 and the overall stability turned Ruby on Rails into one of the most prominent frameworks available. The evolution of the web servers that supported Rails was not as steady as one could want though.

First there was WeBrick. Although being quite a reasonable web server, it suffers with performance issues due to the fact of being 100% written in Ruby.

And then there was FastCGI…

Then there was a CGI module for Apache. Not bad, but still far away from what should be expectable from a production level web server. Not long after a FastCGI module surged to speed up things — and it did. Using Apache on a production system was now reliable without incurring in memory leaks. Also, you could still use the usual load balancing mechanisms (like mod_proxy_balancing) to distribute the load amongst several machines.

Speedy Lighty

Soon thereafter, WeBrick was replaced as the default development web server by Lighttpd or simply lighty. This web server is quite fast and is used on some big websites. Unfortunately, it’s not that effective against a very big load. Lighttpd processes usually get to a stage that only a reboot can kill them [1].

Ruby HTTP server reborn - Mongrel

Recently, a new player has reached version 1.0. Mongrel launched its first stable version on the same day that Rails 1.2 was released. It’s written in Ruby, like WeBrick, but much faster.

Wave down Apache..

Most people started realizing that Apache could be an overkill option for running Ruby except if you actually required it (for instance, for running PHP). Some started using Lighttpd for spawning FastCGI processes and others started leveraging Apache’s dependence by only making use of mod_proxy_balancer that would then distribute the requests amongst some Mongrel instances. This last method works quite good and it’s especially suited for multi-core processors, where you can set a Mongrel instance to run on a specific core. Great performance can be achieved using that technique.

It’s all about Russia, stupid

And then, when everyone had already settled down with a nice, reliable and fast solution for serving Ruby, ngnix comes into town. ngnix is a wholly fast web server that serves static files in a breeze. And also does load-balancing. Got the point? Serving Mongrel instances through ngnix. ngnix is chiefly developed by russians and English documentation is still lacking so if you need assistance to get started check this post.

Who’s missing?

LiteSpeed. I feel compelled to a note here. LiteSpeed is a commercial option. They do have a free (as in free beer) version available but it’s not so fine-tuned as the enterprise one, which costs loads of money.

LiteSpeed comes to town

LiteSpeed does not rely on FastCGI instances nor Mongrel. It runs Ruby through LSAPI and until further news, it has achieved the best scores I’ve seen.

Conclusion

One should note that there’s no silver bullet and depending on the requirements your mileage may vary. Using named pipes instead of TCP while passing the requests to the handler makes a huge of a difference. On the other hand, doing it through sockets makes it much more difficult to apply load balancing mechanisms. Overall, LiteSpeed is great. If you want to keep a Free/Open Source Software solution though I would suggest using ngnix with Mongrel.

It’s all about the statistics

I’ll leave you with some websites that did some benchmarking

• http://blog.kovyrin.net/2006/08/28/ruby-performance-results/lang/en/
• http://blog.litespeedtech.com/articles/2006/08/31/my-rails-benchmark-results-lsws-lsapi-vs-nginx-fcgi

[1] - This shall be addressed in version 1.5