Grails again on the Radar: Now Seam

Answering a question from the comments some posts back.

"Hi again,

You might have read this …


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.

Groovy and IDEA, a mixed blessing [Updated]

I've been an Intellij IDEA user from the very, very beginning. I think we bought some of the first licenses. I've been promoting IDEA against Eclipse cultures for years. IDEA is the most usable IDE around. I've got several companies I worked for to buy IDEA although they are Eclipse shops. I got all people in the team I manage to use IDEA instead of Eclipse. I converted Eclipse users. I'm an evangelist. I love IDEA!

Now I've been working on Grails for some time, thinking about using it in a project and deciding if it's better than JS for the task. And the Groovy support in IDEA is very very bad. The plugin is not from Intellij, but it reflects badly on them. So I have to decide if I should use Grails for the project, drop IDEA and move to Eclipse or drop Grails and stay with IDEA. Groovy with the current plugin is no option in the long run. Going to the forums on the IntelliJ site reveal lots of discouraging comments by IntelliJ employees. Groovy seems to have a much lower priority than Scala (very nice, but who uses it?), Ruby, Python and JS. And that although Groovy seems a natural choice for Java. When I, a long time IDEA user drop IDEA as a Java developer, they will lose a customer from their core group (Java developers) which sounds stupid from a marketing and sales point of view.

What a difficult choice, but currently I lean on dropping IDEA, after all those years. What can the Grails/Groovy community, the users and developers do to get better support from IntelliJ?

Update (see comments): "Actually right now the situation regarding Groovy support has changed, which you may have found out from recent forum posts. We are no longer actively developing the Scala plugin, and the team responsible for it is now working on a new Groovy plugin."

Rails and Grails: A language shootout?

Following the benchmarking, I think it's a very good idea from Graeme to stop benchmarking until Grails gets some optimizations. Currently performance should not be a big concern for the Grails developers. Keeping up the good work with implementing features and fixing bugs should stay their main concern.

When looking at the Grails versus Rails benchmarks, I thought this might be more about languages than web frameworks.

Rails: Ruby
Ruby: Ruby/C
MySQL driver: C/Ruby
Mongrel: Ruby/C

Grails: Java/Groovy
Groovy: Java/Groovy
Java: Java/C
MySQL driver: Java
Tomcat: Java

(Correct me if I'm wrong please)

It's great news to me that for example mongrel is primary ruby. Some years ago when I did some projects with Ruby, a lot of stuff was written in C and needed to be compiled, which is always a lot of pain. Also the code looks quite good and clean. And they thought about performance:

# Does the majority of the IO processing.
# It has been written in Ruby using
# about 7 different IO processing strategies
# and no matter how it's done
# the performance just does not improve.
# It is currently carefully constructed
# to make sure that it gets the best possible
# performance [...]

Good to see.

So is this about Rails versus Grails or Ruby versus Groovy or C versus Java? But as I said in the beginning, I think it's a very good idea from Graeme to stop benchmarking until Grails gets some optimizations

Rails versus Grails

Hu, the performance wars seem to have to started. I'm not really into performance, as long as it's fast enough. But some people demand an optimized Rails setup. As far as I'm concerned the benchmarks by Graeme was about two out of the box solutions. They showed that people can decide to use Grails over Rails without fear of a slow solution. If people earn money with Rails they can with Grails. There is no sense in optimizing one solution without the other. Right out of my head there are some optimizations for the Grails setup one might try:

- Use the fastest JDK, not JDK 5 but JDK 6 (7? Or 3rd party JDK). JDK 5 is not the fastest one
- Use the JDK on the fastest plattform
- Use fastest database (H2 not MySQL)
- Tune VM parameters (GC and object creation)
- Use faster application sever (Resin instead of Tomcat?)

These are very easy ones, just change the command line or the application setup. More diffucult optimizations are Hibernate tuning or using another ORM (Toplink?), move to a clustered setup (makes only sense with several servers), caching etc.

I think I'll take a look into some of the options, just to tune my Grails application.

Update: After some research, Resin in the open source version is quite slow, Jetty might be slightly faster than Tomcat