A solution to scaling Ruby on Rails
Given the recent interview where Alex Payne from Twitter mentioned their scalability issues, and after I write about it yesterday, it finally dawned on me what the perfect solution would be.
Naturally, that solution is to use JRuby and take advantage of a good JEE container! Given the current state of JRuby, it seems that JRuby is pretty darn close to being able to handle a big production app like Twitter.
Java’s VM’s have come a long way in the last few years and there is no reason not to take advantage of them, along with the two predominate servlet containers like Tomcat and Jetty. There is even a recent post about Tomcat being able to handle some 16,000 connections without too much trouble.
Not only would you get the maturity of a modern JVM, but you could also benefit from the mature JDBC drivers out there as well. The MySQL driver for instance allows you to specify multiple servers to connect to.
Don't miss anything, subscribe!
Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.
Comments
I think it certainly could be. The only real barrier I see at the moment is getting the word out and overcoming in Java related FUD.
I completely missed the connection pooling of the app server (duh…) 
Prepared statements would be a big plus as well. Any DBA worth his certification will tell you that dynamic SQL isn’t good. I think this area is really missed since a lot of people going to rails is coming from PHP and related languages that don’t normally use prepared statements.
I’m trying deployment of my Rails apps on the JRuby/JVM platform too currently. At first to have a deployment with one instance only to administrate, taking advantage of the thread-pooling of Java application servers.
But with respect to raw performance the JVM still needs some support for dynamic languages, doesn’t it? Here http://www.infoq.com/presentations/gilad-bracha-dynamic-languages-jvm Gilad Bracha talks about this, especially the invokedynamic bytecode. When (if) this becomes implemented, we might start to get some of the benefits that we get today with Javas static way of working. Like hotspot compiling and the like.
Until then, we must rely on the JRuby JIT-stuff. If not, it will be interpretation of a VM-based languange on top of another language…
I’ve been working on implementing prepared statements support in Ruby on Rails. You can read about it here: http://izumi.plan99.net/blog/?p=35
I’ve mailed rubyonrails-core about this. Some people seem to be skeptical about the usage of prepared statements. Some argued that prepared statements can be a bit slower (because it requires an extra database roundtrip), and according to benchmarks, they are (at least for MySQL). What are good reasons to use prepared statements over regular (”manually built”) SQL statements?
Good reasons for using prepared statements are:
* Server better able to cache and reuse execution plans for sql-statements on server-side. It takes time/resources for db-server to parse and prepare an execution plan for a sql-statement. If it reads “select foo from bar where bleech = 42″, it needs to be re-parsed when it comes in again with “select foo from bar where bleech = 666″. Had it been “select foo from bar where bleech = :value”, the execution plan could have been reused.
* Some java app-servers can cache prepared statement objects and reuse on client side. Weblogic for instance, can do this. Of course, there needs to be connection pooling to, then.
* Security: Many issues with sql-injection disappears, as doing for instance preparedStatement.setString(1, “blah ‘blah’ blah”) will automatically escape the “illegal” chars in the driver.
A few other points in our favor:
- JRuby on Rails deployed to a clusterable app server like GlassFish will use GF’s session replication (this is not yet working, but it’s planned)
- JRoR will use a Java connection pool for sharing database connections
- Some proof-of-concept work has been done with JRoR to use prepared statements. The tricky bit seems to be deciding when to prepare statements, since Rails generates a lot of different SQL. It’s a JIT-like question
- There are also bound to be efforts soon to build things like ActiveHibernate or ActiveJPA, to allow using a more Java/Appserver-friendly ORM layer that’s still Rails-feeling. See Ola Bini’s blog for a bit of discussion on that.
We certainly hope that JRuby will be an option (perhaps THE option) for large, scalable Rails apps, and we’re looking for anyone and everyone to help us get there.