So after a couple of people pointed out my naivety in configuring Rails, I decided to re-run the tests. What I did was configure Rails with a 10 mongrel cluster and the Pound load balancer as per Jared's recommendation. However, to make things more equal I reduced the Grails Tomcat server's thread pool down to 10 by setting maxThreads=10 in Tomcat's server.xml.
The result was that Rails' performance degraded in all except the long running query test, whilst Grails' performance significantly improved in all except the same test. Clearly, since I have only dual core's on my MacBook giving Rails or Grails more processes doesn't necessarily improve things for the shorter tasks. Check out the updated benchmarks.
Again, I'm no Rails performance tuning wizard so if any Rails expert can suggest improvements to the Rails configuration please don't hesitate to shout.
Saturday, March 24, 2007
Friday, March 23, 2007
Grails vs. Rails Benchmark
This article: http://thoughtmining.blogspot.com/2007/03/where-are-all-groovy-andor-grails.html
Prompted me to do this:
http://docs.codehaus.org/display/GRAILS/Grails+vs+Rails+Benchmark
Feedback welcome.
I must stress this is not meant to be a flame war inciting benchmark, it has been done merely to allay the aforementioned bloggers fear that he expresses in this comment:
"Surely someone close to the respective projects has asked these hard questions of themselves?
Because I know the previous paragraph has to, has to, be true, then I can only assume one thing: someone has done this as an exercise...and the results were depressing. Why else would the results not be published? If Groovy or Grails was faster, even slightly so, then you can bet it would trumpeted far and wide. The fact that it's not leaves an unsettling feeling."
Prompted me to do this:
http://docs.codehaus.org
Feedback welcome.
I must stress this is not meant to be a flame war inciting benchmark, it has been done merely to allay the aforementioned bloggers fear that he expresses in this comment:
"Surely someone close to the respective projects has asked these hard questions of themselves?
Because I know the previous paragraph has to, has to, be true, then I can only assume one thing: someone has done this as an exercise...and the results were depressing. Why else would the results not be published? If Groovy or Grails was faster, even slightly so, then you can bet it would trumpeted far and wide. The fact that it's not leaves an unsettling feeling."
Thursday, March 22, 2007
Groovy & Grails at Sun Tech Days - The Report
I've been meaning to write up a report of how my workshop on Groovy & Grails at Sun Tech Days went, so here it is. First off, I would like to say a big thanks to the guys at Sun for hosting me, it was great gesture and thankfully we'll see more of it at JavaOne.
As far as the workshop went, I really wanted to deliver something of value and probably ended up overdoing it as a I had over 160 slides (death by keynote!). Fortunately, the audience were extremely enthusiastic with the only hiccup being a gentlemen who was running a p3 450mhz machine with 256mb of RAM and Windows 98 (with MS-DOS!) not being able to get the Grails command line scripts running.
Interestingly, the majority of attendees were from either the banking or insurance industries, which reflects Grails' growth in the enterprise market space. There were many wow moments, and some concepts which were difficult to grok for a group of Java developers. Explaining closures was particularly fun.
Overall, the attendees seemed to enjoy the workshop and left brimming with ideas of how to integrate Grails into their existing systems. Job done.
As far as the workshop went, I really wanted to deliver something of value and probably ended up overdoing it as a I had over 160 slides (death by keynote!). Fortunately, the audience were extremely enthusiastic with the only hiccup being a gentlemen who was running a p3 450mhz machine with 256mb of RAM and Windows 98 (with MS-DOS!) not being able to get the Grails command line scripts running.
Interestingly, the majority of attendees were from either the banking or insurance industries, which reflects Grails' growth in the enterprise market space. There were many wow moments, and some concepts which were difficult to grok for a group of Java developers. Explaining closures was particularly fun.
Overall, the attendees seemed to enjoy the workshop and left brimming with ideas of how to integrate Grails into their existing systems. Job done.
Tuesday, March 20, 2007
Grails Interview on Groovy.org.es
The nice chaps at Groovy.org.es were kind enough to take the time to interview me. For those who want to improve their Spanish and learn what's going on in the Groovy/Grails world check it out.
Tuesday, March 13, 2007
JRuby, Groovy & Java Integration
As a follow-up to yesterdays article, I would like to point out the following article written by Ola Bini on the JRuby team: JRuby Regular Expressions.
This article represents everything that differs in the mentality between the Groovy & the JRuby teams. In essence, the JRuby team are planning on ditching java.util.regex and implementing their own regex parser to match the Ruby regex semantics.
Regardless as to whether this is a good thing or not, and regardless as to whether you can change the default implementation this is the essence of the debate over Java integration. So whenever you drop out of Java and into Ruby-land you need to remember that the semantics differ between regex implementations. To be clear: Java integration means more than just being able to call a method on a Java class.
To quote Dierk Koenig, author of Groovy in Action, who posted this comment yesterday:
"I would like to add that there is a fundamental difference between the two types of languages for the Java platform: type A, which are languages designed specifically for that platform (Groovy, Scala, etc.), and type B, which are ports of a foreign language (Jython, JRuby, Kawa, Bistro, and the likes).
While type B languages can achieve a decent level of interoperability, only type A languages can truly integrate with Java. This is because foreign languages not only have their own libraries, APIs, and such but more important, they come with their own object model, threading architecture, security concept, performance and debugging hooks, and last not least their own runtime architecture that can be fundamentally different from Java. Any type B language has to overcome this impedance mismatch breaking either Java's or the foreign language's behavior.
The acid test for integration is to replace any given Java class (be it abstract, or in the middle of an inheritance chain, or having overloaded methods, or using annotations) and replace it with an implementation in your language. This is what only type A languages can possibly achieve."
In other words, this is another example of how the JRuby developers have to make a hard choice in order to support C Ruby compatibility. Unfortunately on this occasion, it is Java integration that suffers.
In Groovy the expression ~/pattern/ results in an instance of java.util.regex.Pattern therefore the semantics are the same, you can call all the regular JDK methods on the object and the object can be passed to a Java object to hook into other frameworks and tools.
This article represents everything that differs in the mentality between the Groovy & the JRuby teams. In essence, the JRuby team are planning on ditching java.util.regex and implementing their own regex parser to match the Ruby regex semantics.
Regardless as to whether this is a good thing or not, and regardless as to whether you can change the default implementation this is the essence of the debate over Java integration. So whenever you drop out of Java and into Ruby-land you need to remember that the semantics differ between regex implementations. To be clear: Java integration means more than just being able to call a method on a Java class.
To quote Dierk Koenig, author of Groovy in Action, who posted this comment yesterday:
"I would like to add that there is a fundamental difference between the two types of languages for the Java platform: type A, which are languages designed specifically for that platform (Groovy, Scala, etc.), and type B, which are ports of a foreign language (Jython, JRuby, Kawa, Bistro, and the likes).
While type B languages can achieve a decent level of interoperability, only type A languages can truly integrate with Java. This is because foreign languages not only have their own libraries, APIs, and such but more important, they come with their own object model, threading architecture, security concept, performance and debugging hooks, and last not least their own runtime architecture that can be fundamentally different from Java. Any type B language has to overcome this impedance mismatch breaking either Java's or the foreign language's behavior.
The acid test for integration is to replace any given Java class (be it abstract, or in the middle of an inheritance chain, or having overloaded methods, or using annotations) and replace it with an implementation in your language. This is what only type A languages can possibly achieve."
In other words, this is another example of how the JRuby developers have to make a hard choice in order to support C Ruby compatibility. Unfortunately on this occasion, it is Java integration that suffers.
In Groovy the expression ~/pattern/ results in an instance of java.util.regex.Pattern therefore the semantics are the same, you can call all the regular JDK methods on the object and the object can be passed to a Java object to hook into other frameworks and tools.
Monday, March 12, 2007
The Charles Nutter Ruby on Grails story
Back in December Charles Nutter and I had a discussion at JavaPolis about collaborating and the potential to leverage Grails as a platform for multiple languages.
Now Charles has actually looked at the codebase, and would even like a further extended tour (Charles - give me a shout if you're interested, I'd be happy to). His conclusion? Lets make Ruby on Grails. I don't find it particularily suprising he has come to this conclusion. His estimates of Java-to-Groovy are actually way off. I would say if you take away the unit tests and sample apps, Grails is more like 85% Java. There are a few things that should be pointed out here:
With Grails we've embraced the Groovy language idioms like builders, closures and meta-programming in a big way. We've pushed the boundaries of what Groovy is capable of doing. Now say we decided to support JRuby, and maybe JavaScript could we create as elegant a framework by making compromises to support all language idioms? Actually, in this case yes we probably could because Ruby for example as Charles says in his typically "language neutral" way "everything you can do in Groovy you can do in Ruby (plus more)". But how long would that take?
Then there is the Java integration story, which I believe Charles is only getting half of the picture here. Java integration is not just about being able to invoke a method on a Java object. Java integration is about mindshare integration, API integration, syntax integration, object model integration. JRuby has only just managed to solve object model integration, it won't ever be able to solve API, syntax or mindshare integration. What I mean by this is when i create a File, it should be a java.io.File, what about Streams do I forget about those? And the Collections API? Out the window with JRuby. Hang on, when I'm in "Ruby-land" a string isn't a java.lang.String? Telling an organisation that they're going to have to send their entire development team on weeks and weeks of training to understand Ruby and Rails is a hard sell. As Chad Fowler said recently at RailsConf, Ruby is not for "stupid programmers", which effectively means you need well trained people.
And of course then there is Agile and scalable application complexity. Dynamic languages are only useful for small to medium complex applications. This is also "fact". Having supported a multi-tier Perl system for a number of years I would rather die than have to write a complex banking system completely in Groovy or Ruby. But, I would be quite happy to write parts of it in either. If you take this approach you get what I call scalable complexity. The ability to start off in a dynamic language and when things get tricky implement certain parts in Java.
The problem here is that to take this approach you need two languages (one dynamically-typed, one statically-typed) that work seamlessly together. Why? In Agile one of the activities known to reduce productivity is task switching. Read any book on Lean Thinking and Agile and they'll tell you to eliminate waste by eliminating task switching. Switching language idioms is task switching and in this sense the Java-to-Groovy story is just so much stronger. A developer can easily switch between using Java and using Groovy without having to start thinking in a completely different way. This is simply not the case with JRuby.
On the practicality front, Grails 1.0 will be out by Autumn (that's Fall for those on the other side of the pond) or maybe even sooner. By supporting all these languages we'd end up in a situation like Phobos, which is basically going nowhere and does not do a quarter of what Grails or Rails is capable of.
So does all this mean I don't want to support Ruby on Grails? Hell, I would love if we could! Choice is a good thing and with the JVM this is completely possible, its just down to the old conundrum: Resources. So maybe Sun should, instead of wasting their time with dead end projects like Phobos, step up to the plate and commit resources to projects that do matter now. Like Grails.
So why should Sun do this? Well, Grails is beginning to win the battle for the hearts of minds of Java developers looking for the next big web framework. How can I justify this claim?
Now Charles has actually looked at the codebase, and would even like a further extended tour (Charles - give me a shout if you're interested, I'd be happy to). His conclusion? Lets make Ruby on Grails. I don't find it particularily suprising he has come to this conclusion. His estimates of Java-to-Groovy are actually way off. I would say if you take away the unit tests and sample apps, Grails is more like 85% Java. There are a few things that should be pointed out here:
- Not only is it very possible to support other languages, it is feasible now, thanks to the plugin system and Grails' well thought out, as Charles puts it, "interfacified, injectificated, and abstractilicious" design.
- The benefits of leveraging all of the existing dominant libraries in the Java eco-system (Spring, Hibernate, SiteMesh, Quartz) is becoming more clear. There is no doubt that the codebase and libraries being in Java provide a significant performance improvement over Rails (100% Ruby) in my view. Grails is a mere Groovy facade onto a well integrated set of libraries, I've been saying this at ever presentation I've given about Grails since day one. This is one assertion Charles is most certainly correct on.
- We also see these same benefits for people who need a reasonable migration path. Questions like "how can I use my existing Hibernate domain model?", "Can I continue to use Spring MVC controllers?", and "Can I inject and re-use Java services?" all have a clear and well defined answer in Grails making it much easier (although still challenging) to sell into enterprise organisations.
With Grails we've embraced the Groovy language idioms like builders, closures and meta-programming in a big way. We've pushed the boundaries of what Groovy is capable of doing. Now say we decided to support JRuby, and maybe JavaScript could we create as elegant a framework by making compromises to support all language idioms? Actually, in this case yes we probably could because Ruby for example as Charles says in his typically "language neutral" way "everything you can do in Groovy you can do in Ruby (plus more)". But how long would that take?
Then there is the Java integration story, which I believe Charles is only getting half of the picture here. Java integration is not just about being able to invoke a method on a Java object. Java integration is about mindshare integration, API integration, syntax integration, object model integration. JRuby has only just managed to solve object model integration, it won't ever be able to solve API, syntax or mindshare integration. What I mean by this is when i create a File, it should be a java.io.File, what about Streams do I forget about those? And the Collections API? Out the window with JRuby. Hang on, when I'm in "Ruby-land" a string isn't a java.lang.String? Telling an organisation that they're going to have to send their entire development team on weeks and weeks of training to understand Ruby and Rails is a hard sell. As Chad Fowler said recently at RailsConf, Ruby is not for "stupid programmers", which effectively means you need well trained people.
And of course then there is Agile and scalable application complexity. Dynamic languages are only useful for small to medium complex applications. This is also "fact". Having supported a multi-tier Perl system for a number of years I would rather die than have to write a complex banking system completely in Groovy or Ruby. But, I would be quite happy to write parts of it in either. If you take this approach you get what I call scalable complexity. The ability to start off in a dynamic language and when things get tricky implement certain parts in Java.
The problem here is that to take this approach you need two languages (one dynamically-typed, one statically-typed) that work seamlessly together. Why? In Agile one of the activities known to reduce productivity is task switching. Read any book on Lean Thinking and Agile and they'll tell you to eliminate waste by eliminating task switching. Switching language idioms is task switching and in this sense the Java-to-Groovy story is just so much stronger. A developer can easily switch between using Java and using Groovy without having to start thinking in a completely different way. This is simply not the case with JRuby.
On the practicality front, Grails 1.0 will be out by Autumn (that's Fall for those on the other side of the pond) or maybe even sooner. By supporting all these languages we'd end up in a situation like Phobos, which is basically going nowhere and does not do a quarter of what Grails or Rails is capable of.
So does all this mean I don't want to support Ruby on Grails? Hell, I would love if we could! Choice is a good thing and with the JVM this is completely possible, its just down to the old conundrum: Resources. So maybe Sun should, instead of wasting their time with dead end projects like Phobos, step up to the plate and commit resources to projects that do matter now. Like Grails.
So why should Sun do this? Well, Grails is beginning to win the battle for the hearts of minds of Java developers looking for the next big web framework. How can I justify this claim?
- We have had a huge surge in popularity, Groovy in Action is the number one best selling book at Amazon "Java Books"
- There are 12 sessions featuring Groovy and/or Grails at JavaOne.
- Grails is the most popular project at Codehaus.org by a long way.
- Over at JBoss they're scrambling around attending GroovyDevCon meetings and looking to get Groovy incorporated in Seam to bring the same level of elegance to Seam as we have now in Grails. Still, I believe JBoss are on to a good thing, keep up the good work guys ;-)
- JRuby on Rails is being talked about, and noise is being made, but where is the real world use cases? Who is actually deploying JRuby on Rails now? No one. fact. With Grails we have people using and deploying real worlds Grails applications all over the place. In the Java space, JRuby on Rails is playing catchup to Grails and not the other way round. And now we have JRuby on Grails being suggested. How the tables are turning ;-)
- Then we have poor old Phobos, which has managed 38 posts on the user mailing list since June last year. As Charles says, you guys are "damn smart" Sun engineers, so do the smart thing and give up guys, this is going nowhere. On one side of the fence you're saying "use JSF and forget about Javascript!" and now you want people to write it on the Server-side? I love JavaScript, but there are far more elegant languages to include on the server-side. My advice? Join Grails and help make it better and support other languages. We have solutions to most of the problems you're trying to solve now. Why duplicate effort?
- People all over the place are discovering and enjoying Grails. It provides a solution now, everyone else is just talking about a solution.
Friday, March 09, 2007
Grails Session accepted at JavaOne
So here's some additional good news. As well as the Grails event at Sun Tech Days my session submission has passed Hani and the JavaOne panel's strict acceptance criteria and there will be a Grails session at JavaOne! See in San Francisco in May!
PS There may well be something else special Grails related happening at JavaOne, stay tuned.
PS There may well be something else special Grails related happening at JavaOne, stay tuned.
Thursday, March 08, 2007
Grails popularity surges
Well, if mailing list traffic is anything to go by anyway. The latest stats from Nabble show that Grails now has the most popular mailing list on Codehaus ahead of popular projects like Mule, Drools and even our friends on the Groovy list. Of course this could mean nothing at all, but still its nice that we have such a large community growing around Grails.
On a related note, Marcel, one of our committers, has just started up a Frappr map showing where Grails people are located.
On a related note, Marcel, one of our committers, has just started up a Frappr map showing where Grails people are located.
Friday, March 02, 2007
Grails at Sun Java TechDays London '07
For those of you in and around the London area who are interested in Groovy & Grails, I'll be doing a 1-day workshop on Groovy+Grails at Sun's Java TechDays Event (Thanks for the invite guys!) on the 15th of March. The breakdown for the Sun TechDays event is as follows:
- 13th - Day 1 - SunLive (Business Event) & NetBeans innovation/OpenSolaris Day
- 14th - Day 2 - JavaUK & University day
- 15th - Day 3 - JavaUK & Groovy Day
Subscribe to:
Posts (Atom)