Comments on: Are Rails and Grails Scalable? http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/ "Science is a wonderful thing if one does not have to earn one's living at it" -- Albert Einstein Sat, 22 Nov 2008 03:16:30 +0000 http://wordpress.org/?v=2.6 By: Joseph Nusairat http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-48463 Joseph Nusairat Mon, 14 Jan 2008 18:37:33 +0000 http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-48463 This is an old blog posting i know, but I was wondering if you have thought of retesting this now that Seam 2.0 is out, Rails can run under tomcat (mongrel by a few people I have talked to is a mongrel), and Grails 1.0 is almost out? Would be interesting to see the changes ciao This is an old blog posting i know, but I was wondering if you have thought of retesting this now that Seam 2.0 is out, Rails can run under tomcat (mongrel by a few people I have talked to is a mongrel), and Grails 1.0 is almost out?

Would be interesting to see the changes

ciao

]]> By: Andy http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-12969 Andy Tue, 17 Apr 2007 13:30:18 +0000 http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-12969 Michael with all do respect I think your numbers are too high. Most real apps have greater contention than this. Because Seam/Hibernate supports optimistic locking scenarios and is really optimized for MVCC/Snapshot isolation...I would expect its performance to be at least a full magnitude greater under contention. I think as you mention this mostly tested CPU contention/IO utilization and probably the efficiency (in the case of ruby) of the driver implementation. I would be much more curious to see scalability under contention than these kinds of raw numbers (and of course some hardware to go with it)... Probably you can't do that on your laptop though :-) Michael with all do respect I think your numbers are too high. Most real apps have greater contention than this. Because Seam/Hibernate supports optimistic locking scenarios and is really optimized for MVCC/Snapshot isolation…I would expect its performance to be at least a full magnitude greater under contention. I think as you mention this mostly tested CPU contention/IO utilization and probably the efficiency (in the case of ruby) of the driver implementation. I would be much more curious to see scalability under contention than these kinds of raw numbers (and of course some hardware to go with it)… Probably you can’t do that on your laptop though :-)

]]> By: Modoc http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-12920 Modoc Mon, 16 Apr 2007 22:29:24 +0000 http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-12920 @Uberdude: I don't have the numbers handy anymore, but my simple seam app running on a 2 year old single proc budget server took a slashdotting, combined with a digging, and a Yahoo tech article linking amazingly well. Obviously that's no comparison to any other toolset, but personally I was surprised at how well it handled the load. @wgaf: I haven't looked where we rank, but Cingular moves orders of magnitude more traffic than that. Scaling beyond those numbers are very important for many sites. @Uberdude: I don’t have the numbers handy anymore, but my simple seam app running on a 2 year old single proc budget server took a slashdotting, combined with a digging, and a Yahoo tech article linking amazingly well. Obviously that’s no comparison to any other toolset, but personally I was surprised at how well it handled the load.

@wgaf: I haven’t looked where we rank, but Cingular moves orders of magnitude more traffic than that. Scaling beyond those numbers are very important for many sites.

]]> By: Rich Collins http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-12915 Rich Collins Mon, 16 Apr 2007 21:00:01 +0000 http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-12915 You are confusing the cost of scaling with the ability to scale. It is more expense to scale Rails and Grails, but they scale just fine. The choke point is almost always the DB. If you want to scale, make sure that the DB can be scaled (most can't once you are update bound). You are confusing the cost of scaling with the ability to scale. It is more expense to scale Rails and Grails, but they scale just fine.

The choke point is almost always the DB. If you want to scale, make sure that the DB can be scaled (most can’t once you are update bound).

]]> By: Robert http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-11101 Robert Thu, 29 Mar 2007 18:32:04 +0000 http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-11101 Graeme is right, scalability and performance are two different things. There is also scaling horizontally, via hardware and vertically via more CPU per hardware. For some scenarios, it would be far cheaper to build quickly, say via Grails, and deploy on cheap hardware and be able to add to that hardware than to build bigger and deploy on bigger hardware. You also have to take into account the server it is running under. maybe Grails will run better under Glassfish or Jetty or weblogic, or whatever. Some of the request-per-second time is going to be dependent on the servlet engine in use. Not all, but some. Regardless, until we see a head-to-head match Seam vs. Grails one can only speculate Graeme is right, scalability and performance are two different things. There is also scaling horizontally, via hardware and vertically via more CPU per hardware. For some scenarios, it would be far cheaper to build quickly, say via Grails, and deploy on cheap hardware and be able to add to that hardware than to build bigger and deploy on bigger hardware.

You also have to take into account the server it is running under. maybe Grails will run better under Glassfish or Jetty or weblogic, or whatever. Some of the request-per-second time is going to be dependent on the servlet engine in use. Not all, but some.

Regardless, until we see a head-to-head match Seam vs. Grails one can only speculate

]]> By: wgaf http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-11052 wgaf Thu, 29 Mar 2007 11:30:21 +0000 http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-11052 Please read carefully - my comment was, very few sites handle that number of requests per second. Nothing else :-) The obversations and assertions you are making are based on a specific traffic scenario that really doesn't very many web sites. Please read carefully - my comment was, very few sites handle that number of requests per second. Nothing else :-)

The obversations and assertions you are making are based on a specific traffic scenario that really doesn’t very many web sites.

]]> By: Gavin http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-11037 Gavin Thu, 29 Mar 2007 05:01:56 +0000 http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-11037 Certainly I would not expect the current architecture of Ruby on Rails to scale like a Java EE based solution - but I'm not sure that I agree that Grails should not in principle exhibit comparable performance and scalability in simple cases. After all, Groovy compiles down to Java classes just like ordinary Java. I expect that if the Grails team goes through the full process of identifying contention points and optimizing performance, Grails should scale comparably to Seam at least for simple stateless usecases. (Seam will probably still have the edge in optimistic txn processing, however, due to the conversation model.) So this is probably more an indication of maturity than of any deep architectural problem in Grails. Certainly I would not expect the current architecture of Ruby on Rails to scale like a Java EE based solution - but I’m not sure that I agree that Grails should not in principle exhibit comparable performance and scalability in simple cases.

After all, Groovy compiles down to Java classes just like ordinary Java. I expect that if the Grails team goes through the full process of identifying contention points and optimizing performance, Grails should scale comparably to Seam at least for simple stateless usecases. (Seam will probably still have the edge in optimistic txn processing, however, due to the conversation model.)

So this is probably more an indication of maturity than of any deep architectural problem in Grails.

]]> By: Michael Yuan http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-11034 Michael Yuan Thu, 29 Mar 2007 02:55:45 +0000 http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-11034 Uberdude, I know. That is why I said "take my word with a grain of salt". ;) We are not ready to publish because, frankly, Rails/Grails are not our performance objectives. As Graeme said, it is to be *expected* that a pure Java solution will outperform a scripting language based solution. They have different strengths. cheers Michael Uberdude,

I know. That is why I said “take my word with a grain of salt”. ;) We are not ready to publish because, frankly, Rails/Grails are not our performance objectives. As Graeme said, it is to be *expected* that a pure Java solution will outperform a scripting language based solution. They have different strengths.

cheers
Michael

]]> By: Uberdude http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-11030 Uberdude Thu, 29 Mar 2007 00:53:25 +0000 http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-11030 When will we see some benchmarks for Seam? While there are lots of "proven" marks for Grails, we simply have the 5-10 magic hand wave for Seam :) So until you can put up numbers to prove the point isn't this all somewhat moot? When will we see some benchmarks for Seam? While there are lots of “proven” marks for Grails, we simply have the 5-10 magic hand wave for Seam :) So until you can put up numbers to prove the point isn’t this all somewhat moot?

]]> By: Michael Yuan http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-11026 Michael Yuan Wed, 28 Mar 2007 23:56:22 +0000 http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/#comment-11026 wgaf, First of all, you are quoting "average" while a site should really handle "peak" traffic. Second, keep in mind that the "benchmark" numbers here are for very simple apps with very limited concurrent users. It will be slower when you have a lot of user states to manage. According to your logic, no one will ever need to use server clusters? In fact, plenty of people do need better performance for all kinds of reasons. Last, without resolving CPU contention points, the CPU will eventually rise to 100% within several hours and render the site unusable -- then you cannot even serve 1 request per second. ;) cheers Michael wgaf,

First of all, you are quoting “average” while a site should really handle “peak” traffic.

Second, keep in mind that the “benchmark” numbers here are for very simple apps with very limited concurrent users. It will be slower when you have a lot of user states to manage.

According to your logic, no one will ever need to use server clusters? In fact, plenty of people do need better performance for all kinds of reasons.

Last, without resolving CPU contention points, the CPU will eventually rise to 100% within several hours and render the site unusable — then you cannot even serve 1 request per second. ;)

cheers
Michael

]]>