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
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
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.