Grails again on the Radar: Now Seam
Published March 29th, 2007 in GeneralAnswering a question from the comments some posts back.
“Hi again,
You might have read this …
http://www.michaelyuan.com/blog/2007/03/28/are-rails-and-grails-scalable/
[…]”
Well, a vendor says his product is best? Why should he say something else?
“While Grails beats Rails in the benchmark, it looks to me neither of them is scalable in a multi-core environment. From our internal tests, JBoss Seam easily out-performs both by a wiiiiide margin (5 to 10 times higher throughput than the published Rails/Grails numbers).”
As Graeme said before, the benchmarks are not about scalabilty but performance. So the comment by Michael is completely off target. Either he doesn’t know better or he’s a troll.
“If you do a JVM thread dump here (or something equivalent in Ruby), you will see most threads are waiting and the CPU load slowly creeps up to 100% as the backlog increases.”
Did he do it? No. He just tells us that if we would do it, we will see his predicted result. Can he look into the future?
“So, let’s look at Graeme’s response time graph. The max response times are indeed extremely long — consistent with hang threads.”
Or because Groovy/Grails does some code and GSP compilations? Or something completely different happens? Or GC? Who knows without looking?
So all FUD no content in that article. His ideas might sound good and perhaps might help increase performance in Grails, but he needs to prove his points with data. Otherwise - FUD. Do they already feel the heat?
The suprising part though is the comment by Gavin, very polite.
Ahem. Graeme is also a vendor, and his benchmark of a competing product, which also showed his “product is best”, could be taken in the same light - but you didn’t call his work “FUD”, did you?
I’m not by any means an expect on scalability testing, but Michael’s reasoning (the main part of which you conveniently ignored in this post) looks very sound to me, and hopefully points the Grails guys in the right direction in terms of performance optimization.
Now, I always maintain a position of extreme skepticism with respect to benchmarks of toy applications run on people’s laptops, and of benchmarks in general, so I really doubt the significance of any of these results unless they are reproduced in a non-toy environment against a “real” production database.
But if Graeme wants to publish benchmark results, it’s only fair for other people to come along and point out the warts.
BTW, we all love Groovy and Grails here: it is one of the efforts that is bringing Java forward, rather than holding Java back - and so we have zero interest in FUD-ing Grails. Please don’t be so thin-skinned. Take it as constructive criticism.
Hi Gavin, thanks for your reply.
Yes possibly Graemes posts are influenced by being a vendor himselft. But this post was about Michaels article, not about one by Graeme. And Graeme posted data and the source to redo the tests. Michael only posts his opinions (perhaps backed by his experience from scaling applications).
The reasoning looks sound to me too, as I said in the post. But there are lots of other reasons which would look as sound. And yes, I maintain a position of skepticism too. But as Graeme wrote, the benchmark were not about showing that Grails is faster than X, but that Grails is fast enough right now to base your business decision on it (with the assumption that people earn money with Rails).
There might be faster and more scalable technologies than Grails (I’m sure Seam is faster as a pure Java solution), but business value can be achieved with the current Grails performance level. You can perhaps save money with other solutions (if the hardware you save is more expensive than the man power you have to add when you use a technology which is more work intensive than Grails.)
“But if Graeme wants to publish benchmark results, it’s only fair for other people to come along and point out the warts.”
Well, Michael didn’t point out any warts, he speculated about the reason why seam is 5x - 10x faster (Michaels words) than Grails. And Graeme did publish the results because people made the assumption that there are no benchmarks because the performance of Grails is abysmal bad.
“Take it as constructive criticism.”
As I said, the criticism might help, but we don’t know, as Michael speculated but didn’t provide data. I think everyone would be thankful if he would provide substance ;-)
Stephans,
Chill, please! I probably should have never made the comment about Seam outperforming Grails without publishing real numbers — my fault here.
But the rest of my post is completely about the scalability of Grails in the context of multi-core processors. I am merely stating my observations and hypothesis based on the data Graeme publishes — how is that FUD? I am hoping that the Grails team will do a thread dump or investigate the 15 seconds response times. I am not a Grails developer after all. But if someone pointed out Seam has this problem, I will investigate it rather thaing calling FUD. ;)
cheers
Michael
Hi Michael,
thanks for your reply. I’m sure, the team will investigate the ‘problem’, if there is one (and it’s not startup code, in the end it’s not Java but Groovy). The Grails developers said several times that performance optimizations are on the roadmap, not just now :-)
“As I said, the criticism might help, but we don’t know, as Michael speculated but didn’t provide data. I think everyone would be thankful if he would provide substance ;-”
and
“So all FUD no content in that article. His ideas might sound good and perhaps might help increase performance in Grails, but he needs to prove his points with data.”
cheers
-stephan