You do what you do with any other bottleneck. You take measurements,
understand what your application is doing and then address it. What
you don't do is panic: Just because Rails might not be able to run
Ebay 'out of the box' doesn't mean that it is a pile of junk.
There are loads of solutions. A few examples are:
- Scale, replicate and cluster your database. Oracle cracked this
- Does all of your data in the database need to talk to all of the
other data? If it doesn't then partition the data along the
appropriate fault lines. Technologies such as Amazon EC2 allow you to
launch a complete machine per client per application per database if
you want. 'Shared nothing' is more than just avoiding threads. It
means don't share anything unless you have to - because bottlenecks
happen at the coupling points.
- Split the application and glue it together with REST calls. It
doesn't all have to live in one stack. Splitting the stack gives you
multiple databases. For example you could have a historical
application that looks after what was happening yesterday, and a live
application that looks after what happened today, with an archiving
process moving rows between the two. Today is what is important and
that has the fast response, triggering an AJAX call to the
'historical' stack which may take a little longer to respond.
But most importantly don't throw the baby out with the bathwater. Ruby/
Rails gives you productivity by solving the problems inherent in web-
apps. If you suddenly find you have a hit on your hand then that is a
good problem to have - spend some of the money on fixing and improving
the framework/infrastructure/language interpreter, or more likely your
But in the vast majority of cases scaling is a non-issue. It is much
more important just to get the app written and written quickly -
that's where Rails still wins.