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

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

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 ;-)

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.