Comments on: A solution to scaling Ruby on Rails http://thebull.macsimumweb.com/a-solution-to-scaling-ruby-on-rails Thoughts on poker, programming and other stuff. Thu, 08 Jan 2009 18:04:38 +0000 http://wordpress.org/?v=2.7 hourly 1 By: New Mexico http://thebull.macsimumweb.com/a-solution-to-scaling-ruby-on-rails/comment-page-1#comment-1358 New Mexico Sat, 19 May 2007 02:57:33 +0000 http://thebull.macsimumweb.com/2007/04/16/a-solution-to-scaling-ruby-on-rails/#comment-1358 Warm greetings! Thanks for all the information, a very nice and well done site! Cheers. Warm greetings! Thanks for all the information, a very nice and well done site! Cheers.

]]> By: Per Olesen http://thebull.macsimumweb.com/a-solution-to-scaling-ruby-on-rails/comment-page-1#comment-1334 Per Olesen Thu, 17 May 2007 07:33:34 +0000 http://thebull.macsimumweb.com/2007/04/16/a-solution-to-scaling-ruby-on-rails/#comment-1334 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. 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.

]]> By: Hongli Lai http://thebull.macsimumweb.com/a-solution-to-scaling-ruby-on-rails/comment-page-1#comment-1327 Hongli Lai Wed, 16 May 2007 20:50:54 +0000 http://thebull.macsimumweb.com/2007/04/16/a-solution-to-scaling-ruby-on-rails/#comment-1327 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? 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?

]]> By: JRuby on Rails in Tomcat Just Works! « Kiyo’s Blog http://thebull.macsimumweb.com/a-solution-to-scaling-ruby-on-rails/comment-page-1#comment-1215 JRuby on Rails in Tomcat Just Works! « Kiyo’s Blog Thu, 03 May 2007 21:44:32 +0000 http://thebull.macsimumweb.com/2007/04/16/a-solution-to-scaling-ruby-on-rails/#comment-1215 [...] I am really looking forward to JRuby 1.0. It’s a very exciting time. [...] [...] I am really looking forward to JRuby 1.0. It’s a very exciting time. [...]

]]> By: Per Olesen http://thebull.macsimumweb.com/a-solution-to-scaling-ruby-on-rails/comment-page-1#comment-1088 Per Olesen Wed, 18 Apr 2007 16:23:48 +0000 http://thebull.macsimumweb.com/2007/04/16/a-solution-to-scaling-ruby-on-rails/#comment-1088 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’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…

]]> By: The Bull http://thebull.macsimumweb.com/a-solution-to-scaling-ruby-on-rails/comment-page-1#comment-1080 The Bull Mon, 16 Apr 2007 19:39:17 +0000 http://thebull.macsimumweb.com/2007/04/16/a-solution-to-scaling-ruby-on-rails/#comment-1080 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 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.

]]> By: Charles Oliver Nutter http://thebull.macsimumweb.com/a-solution-to-scaling-ruby-on-rails/comment-page-1#comment-1079 Charles Oliver Nutter Mon, 16 Apr 2007 18:26:17 +0000 http://thebull.macsimumweb.com/2007/04/16/a-solution-to-scaling-ruby-on-rails/#comment-1079 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. 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.

]]>