Apache has long appeared to be the only viable show in town for your Rails’ web serving needs when it comes to running a production system. Of course, there has always been many others, but beside my brief fling with thttpd, I’ve never actually been terribly interested in an alternative. That was before discovering lighttpd.
Where Apache is the swiss army knife of web serving, and a great swiss army knife, lighttpd is much lighter and focused. It’s driven by a single lead developer that’s incredibly available (now where did I see that work before…) and has pretty much all the features you need to make a great web server for Rails applications.
What made me particularly interested is the strong FCGI support, which includes a built-in load balancer to have a single lighttpd process be the entry point to multiple FCGI application servers behind it. In other words, you can scale up without getting a hardware based load balancer, doing round-robin DNS, or running a web server on the application servers themselves.
Today I was playing around with a single lighttpd process playing gateway to FCGI processes on four different application servers. The flexibility that gives to plug in another server into your cluster and be running in no time at all is pretty impressive.
Conveniently enough, Routes is going to rid Rails of the mod_rewrite dependency and open up the caching framework to run without complicated rewriting rules, which in turn means that it’ll work on lighttpd (and other web servers). And I’m doing my best to make Rails friendly to lighttpd and lighttpd friendly to Rails in my experiments running Basecamp and Ta-da List on it. Jan Kneschke is doing a great job already to help push that integration tighter.
So if you’re looking at an easier way to scale your Rails application, then you might be interested in looking into lighttpd already. And you’ll certainly be interested once the early adopters have had the time to familiarize us fully with it, document the process, and adapt the software.