LoLoCoJr

This blog has been running on lighttpd since last week. So far it seems to be the best setup for running Rails app. Of course everyone in the Rails world alread knew this but breaking the Apache habit after 8 years is quite hard. However, I’m convinced now that Rails on top of lighttpd + fastcgi is, at least for me, currently the best deployment stack for production use. I’ve already switched one of our internal Rails app to the same app. Currently testing, the soon to be deployed, commercial project and it’s been smooth sailing so far! Perhaps it’s time to try SCGI again.

Well, it turns out Apache2 + SCGI is not a good match, at least not the way I set it up, by following all the (scarce!) documentation on the subject. I used the SCGI Rails Runner package for running. The benefits of having better control of the Rails processes and the supposed easy clustering setup sounded quite appealing. However I hit a brick wall quite quickly. While attempting some load tests on a new Rails that is going into production somewhere this month I noticed the scgi process hung reliably after only 3 concurrent requests! The only thing I could find in the logs were this:

Errno::ECONNRESET (Connection reset by peer)

After the above error is thrown the connection between Apache2 and scgi is lost and your Rails app is dead in the water (Apache 2.0.54, mod_scgi 1.0, SRR 0.4.3, Rails 1.0, Ruby 1.8.3). Perhaps Ruby 1.8.3 is to blame? I hope Breezy upgrades to 1.8.4 (not likely), Dapper is still a nono, so probably have to self-compile Ruby. Will try this over the weekend. In the meantime I’m testing lighttpd + fastCGI and so far: WOAW!! More on this later..