Stability of Rails

I suspect that the answer to this depends on how intensively your site
operates and how well written the app is.

I am aware of commercial J2EE apps with serious memory leak issues, requiring
reboots of the server every few days. But the issue is not with J2EE, it is
an acknowledged problem in the software. Memory leaks in Ruby/Rails apps
have to be approached with an understanding that the platform will not
prevent bad application code, it only makes it easier to write good
application code.

My observation is that Rails is mature enough for "bread and butter"
applications, and I am using it for small-scaled systems. But it is still
experiencing sufficient teething pains that I do not recommend it
for "enterprise applications" where I work (I hate the overused and poorly
defined designation "enterprise", but I don't have a better designation at
this time of the morning).

The specific issues that I have against Rails are all maturity issues, not
core architecture issues. That means that they will be addressed at some
point in the future, although they may have a low priority with the Rails
developers right now.

1. Rails builds every SQL request dynamically, instead of preparing the
request once and then reusing the prepared statement. When I brought this up
I was told that "The sanitize SQL method takes care of everything, and not
all RDMS's support prepared statements".

The prepare phase of SQL execution can be over 80 percent of CPU usage on the
database server, so turning this into a one-time cost at initialization will
improve performance and scalability enormously. Sanitize methods increase
CPU usage on the application, but do not decrease them on the RDBMS.

What RDBMS' do not support prepared statements? Even MS-Access supports
prepared statements in some form.

For "real work" am running against a database on a maxed out IBM 9000 series
server that averages 85% CPU usage 24x7, and all of the efficiency tricks in
the book have already been applied to existing apps in other platforms.

The system administrator calls me up and says "Your little app is doing 10,000
prepares every hour and impacting everyone else' performance - you'll have to
rewrite it before it goes back into production". I know that there are only
a few SQL statements being executed over and over in my app, but apps on
assorted other platforms will do one prepare each for a few hundred SQL once
at deployment, and run for weeks with those few hundred prepares at startup.

I sincerely hope that I have been misinformed on this point, and that I can be
corrected. In the meantime, this is a serious showstopper for mid-to large
sized shops.

2. A specifc few lines of code in the ActiveRecord are not sensitive to the
possibility that the primary key of a system is not necessarily a sequential
integer token. This impacts Rails' usefulness in interfacing to some legacy
databases and in distributed databases using UUID's for primary keying. The
fix is simple but I have not had the time and energy at the same time to
submit the fix. I can't claim the flaw, but I have to take the hit for not
getting the fix submitted.

This was a showstopper for using rails on a small-scale distributed
application I worked on.

1. Rails builds every SQL request dynamically, instead of preparing the
request once and then reusing the prepared statement. When I brought this up
I was told that "The sanitize SQL method takes care of everything, and not
all RDMS's support prepared statements".

The prepare phase of SQL execution can be over 80 percent of CPU usage on the
database server, so turning this into a one-time cost at initialization will
improve performance and scalability enormously. Sanitize methods increase
CPU usage on the application, but do not decrease them on the RDBMS.

What RDBMS' do not support prepared statements? Even MS-Access supports
prepared statements in some form.

For "real work" am running against a database on a maxed out IBM 9000 series
server that averages 85% CPU usage 24x7, and all of the efficiency tricks in
the book have already been applied to existing apps in other platforms.

Mysql for one didn't support prepared statements until the latest
versions. When we started using prepared statements with earlier
versions that supported them, we had numerous instability problems.
Things might have changed since.

Regardless of this, classes in Ruby are open. No one prevents you from
opening an appropriate connection adapter and adding prepare statement
support. That what we did anyways.

2. A specifc few lines of code in the ActiveRecord are not sensitive to the
possibility that the primary key of a system is not necessarily a sequential
integer token. This impacts Rails' usefulness in interfacing to some legacy
databases and in distributed databases using UUID's for primary keying. The
fix is simple but I have not had the time and energy at the same time to
submit the fix. I can't claim the flaw, but I have to take the hit for not
getting the fix submitted.

This was a showstopper for using rails on a small-scale distributed
application I worked on.

I hope you have time and energy for coping with other frameworks then.

It was stated many times that Rails is not good for you when you use
the database as an integration mechanism with external applications.
Rails places numerous assumptions on your database schema, but most of
them are configurable though.

Kent Sibilev wrote:

Mysql for one didn't support prepared statements until the latest
versions. When we started using prepared statements with earlier
versions that supported them, we had numerous instability problems.
Things might have changed since.

I've had trouble considering MySQL to be a "real" RDBMS because, until
recently, it did not pass the ACID test. It didn't help that one of
our vendors switched to MySQL for the back end a service that is
mission critical to my company, and immediately suffered a number of
costly outages over a period of several weeks.

However, since MySQL bought Netfrastructure and hired Jim Starkey
(architect and major developer of Firebird through all of its
incarnations), things have been improving on that end. I expect to see
some groundbreaking work from them in the next couple of years.

Regardless of this, classes in Ruby are open. No one prevents you from
opening an appropriate connection adapter and adding prepare statement
support. That what we did anyways.

And that is what I intend to do ... about #8 on my list.

>
> 2. A specifc few lines of code in the ActiveRecord are not sensitive to the
> possibility that the primary key of a system is not necessarily a sequential
> integer token. This impacts Rails' usefulness in interfacing to some legacy
> databases and in distributed databases using UUID's for primary keying. The
> fix is simple but I have not had the time and energy at the same time to
> submit the fix. I can't claim the flaw, but I have to take the hit for not
> getting the fix submitted.
>
> This was a showstopper for using rails on a small-scale distributed
> application I worked on.
>

I hope you have time and energy for coping with other frameworks then.

Actually, I usually toss out the frameworks entirely because the
learning curve is too steep. 5 hours to code and test, then 60 hours
to deploy under J2EE just doesn't add up in my books.

Rails is an exception, so far. It is the first framework I have used
that has bought back enough time to more than make up for the learning
curves. It's just not quite there for core applications that really
scale. Ruby and rails' scaling issues are not in the design, but are
all readily correctable (and are being corrected) as the codebase
matures.

I have seen the "10,000 hits per hour" (2.78 hits per second) figure
bandied about in this thread. As long as this is the scale that is
considered a heavy load, rails development will be tied firmly to the
world of small and non-core systems.

A core application can expect to see 60 hits per user per hour, or
60,000 hits per hour for 1,000 users. When I see someone saying "OMG
my application has sustained 60,000 hits per hour for 90 continuous
days and is still stable, what do I do?", then rails will have made it
into prime time.

It was stated many times that Rails is not good for you when you use
the database as an integration mechanism with external applications.
Rails places numerous assumptions on your database schema, but most of
them are configurable though.

The issues though are not with the core design, they are just maturity
of the code base. A simple correction to a very few easily identified
lines of code resolves this in most cases. When I get to #8 on my
priority list, I will submit my proposed corrections so that these few
lines (12 lines, I think) match other code in ActiveRecord.

the guys of eins.de recently (around the beginning of 2006) switched to rails, and i read the articles about that yesterday. they have about 1M hits a day, most of them being within 14 hours), so they are at about 20 hits per second. possibly this article should interest you:

http://poocs.net/2006/3/13/the-adventures-of-scaling-stage-1

2006/8/31,
johnson_d@cox.net johnson_d@cox.net:

Yes, that's volume worth talking about.

I've had trouble considering MySQL to be a "real" RDBMS because, until
recently, it did not pass the ACID test. It didn't help that one of
our vendors switched to MySQL for the back end a service that is
mission critical to my company, and immediately suffered a number of
costly outages over a period of several weeks.

<...>

However MySQL is good enough wor Wikipedia, Flick, Youtube,
del.icio.us, LiveJournal,
Technorati...

Regards,
Rimantas

I have seen the "10,000 hits per hour" (2.78 hits per second) figure
bandied about in this thread. As long as this is the scale that is
considered a heavy load, rails development will be tied firmly to the
world of small and non-core systems.

A core application can expect to see 60 hits per user per hour, or
60,000 hits per hour for 1,000 users. When I see someone saying "OMG
my application has sustained 60,000 hits per hour for 90 continuous
days and is still stable, what do I do?", then rails will have made it
into prime time.

We averaged about 6,000,000 pages per day for about a month (busy season)...

http://img312.imageshack.us/img312/3569/alexavd9.png

-philip

That's a good testimonial.

This is getting way off topic, and people's favorite RDBMS' get to be like a
religion. I shouldn't, but I'll follow it up anyways because I'm a sucker
for debate.

MySQL has been making strides in the direction of ACID compliance. The
purchase of NetFrastructure positions them to become a technical leader in
the next generation of robust RDBMS' for backing web applications. However,
this future release is not the product we are talking about. I don't like to
bash MySQL, but their current product line does not fill the needs for core
real-time business applications.

None of your examples are core real-time business applications, with complex
business logic that must share data concurrently with other dissimilar
applications. They are all primarily web page providers that happen to be
backed by an RDBMS.

There is a difference between a web page service that happens to be backed up
by an RDBMS and a high-volume mission critical real-time decision support
system. Failure to understand that difference almost killed my vendor's
business.

MySQL is ideal for backing mostly static web page services that have only a
small amount of application logic, such as the examples that you provided.
However, their definition of a transaction boundary (statement level) leaves
holes where exceptions (rollbacks) can leave operations that should be atomic
in reliable system in invalid states.

For example, your banks ATM application inserts a transaction record that says
you deposited $1,000,000 to your bank account, then immediately issues an
update to your bank account balance in another table that says that you have
that money in your account. However, an exception occurs in updating your
account balance - power failure, intern Joe trips over the network cable and
yanks it out, the page is deadlocked, or the windoze server blue screen's.

In MySQL, the transaction has been processed but you don't have the money.
You complain, a two week "needle in haystack" hunt ensues, and the IT
director gets fired or goes to jail.

In the more robust model, all you see is that there was a delay in processing
the transaction. You inquire and find out that they had a server problem,
but your money is now where it belongs. The IT director never even hears
about it.

But that is getting way off the topic of the thread - the only pertinent
lesson for this thread is that the stability of the underlying RDBMS and the
application software can impact the users perception of the stability of
Rails, incorrectly. The three concerns must never be confused in the
evaluation process.

A core application can expect to see 60 hits per user per hour, or
60,000 hits per hour for 1,000 users. When I see someone saying "OMG
my application has sustained 60,000 hits per hour for 90 continuous
days and is still stable, what do I do?", then rails will have made it
into prime time.

That would only be 16 req/sec. At 37signals, we're currently doing at
least 40 req/sec during prime time on Basecamp alone. Then add
Writeboard, Backpack, Campfire, and Tada list (which all run on the
same 5-app server cluster). Others, like 43things.com, are doing more
than 3 million dynamic requests per day. And I'm sure there are others
doing even more than that.

This response shows that you understood my point. These applications give a
very good baseline for stability based on volume of hits.

This suite also appears to require a more business logic than the other
applications that have been mentioned on this thread, and the performance
demands of a real-time collaboration support system should not be
underestimated.

The 37signals suite should provide the original poster with a good foundation
for evaluating Ruby and Rails stability.

For the sake of completeness, the app I am using as my baseline for comparison
is a Java servlet app that runs on a single server. It supports 1,000
concurrent users who, essentially, live in the application. Every hit
performs complex real-time decision support and accounting transactions. The
one server is, essentially, maxed out.