techno.blog("Dion")

TJ Vanderpoel has stepped up to the commenter to my earlier entry who claimed bad performance:

As far as scalability, apache with fcgi certainly isn’t the best option, for rails. In our environment we have one lighttpd process serving requests in a round-robin fashion to from 10 to 100 fastcgi rails listeners. We move anywhere from 300 req/second to 1000 req/second with a dual opteron webserver and the fastcgi listeners can be well in back of the webserver. The only feature i’d like to see added to lighttpd is to be able to add fastcgi listeners on the fly, currently you have to restart the webserver to add listeners. Nonetheless, if you’d talked to rails developers you’d have learned lighttpd is the recommended hosting platform for production applications, as it takes care of many of the speed, and all of the scalability issues.

Mod_Perl

There are many options (apache, FastCGI, mod_ruby, builtin dev server, etc), and these options make me think way back to when I was developing a large scale application with mod_perl. This was when mod_perl just came out, and man was it a pain to test our app under it.

The biggest problem was that at the time, many module writers, and coders in general, didn’t have to care about memory leaks that may occur in CGI scripts. The process is nuked in a few ms, so why both trying to hunt them down?

mod_perl showed everyone how much bad stuff was around :) It was a little like taking someone who has only developed with “implements SingleThreadModel” and taking that out of their servlets. Items they never ran across would now rise up :)

Watch lighttpd and the updated Rails 0.10.0

There is an updated screencast of Rails 0.10.0 which features lighttpd.

You will see some of the changes in the new release, and as always, it is always interesting to see when ‘errors’ show up and how the man behind the screencast solves them. I am always surprised when browser windows are started, that the default page isn’t always about:blank or about:mozilla ;)

Great stuff :)