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.