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, Ive 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. Its driven by
a single lead developer thats 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 itll work on lighttpd (and other web servers). And Im
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
So if youre looking at an easier way to scale your
Rails application, then you might be interested in looking into
lighttpd already. And youll certainly be interested once the early
adopters have had the time to familiarize us fully with it, document
the process, and adapt the software.