On Thu, 10 Apr 2008, Chris Guo wrote:

> "In another incident in the same article, the original Rails author
> admits that the original Rails code required about four hundred
> restarts a day, or six to seven restarts per thread per day. Four
> hundred restarts a day means four-hundred chances for a database
> transaction to fail...."
> The question is:  Is the statement true?

True, but there is some important contextual information that is missing.

> Why should I concern this? Because my next project will be a
> webgame(for thoese who don't know webgame, please visit www.travian.com).
> I'm considering use Ruby on rails to develop this web app. For such
> application, beging stable is extremedly important or the player will
> leave with anger when data was lost, data being inconsistency or
> something like that.
> If the statement is true, then should I turn from rails to Pylons?

The information about the original Rails, running the original BaseCamp, 
requiring 400 restarts per day lacks a great deal of context, and context 
is important.

First, regarding the actual issue of the restarts, it is very important to 
note that this was the _original_ Rails (which was changing very 
frequently -- go back and check the logs for release announcements from 
back then; they were often only a few days apart), which was running on 
fastcgi.

Additionally, one thing that I have never seen mentioned is just what 
those 400 restarts a day really were.  Since the code was running on 
fastcgi, were they just restarts originating in mod_fastcgi's management 
of external processes?  If so, there's nothing really incriminating there.

Also, bear in mind that fastcgi is not the prefered way of deploying Rails 
apps these days, and in fact isn't even common.  This information about 
restarts just isn't particularly relevant to today's Rails.

I know that Rails gets intermixed with Ruby in many people's minds these 
days, but consider, too, that Rails != Ruby.  There are several good, 
capable ways of doing web app development using Ruby today that don't 
involve Rails at all, and which have different sets of strengths and 
shortcomings than Rails.  If you are concerned, maybe you should be 
looking at some of the alternatives?


Kirk Haines