...I can't find a SINGLE benchmark comparing Groovy to competing technologies on the JVM (JRuby, Beanshell, Jython) or dynamic languages in general (Ruby, Python, Perl, and so on). Nor can I find any benchmarks concerning how Grails stacks up to JRuby on Rails, Ruby on Rails, vanilla Hibernate/Spring (something Grails uses under the covers), etc...
In response to this the grails community posted some rough unscientific numbers on Grails versus Rails. Among the benchmarks results:
[In respect to read performance]...Grails is able to handle 40 requests per second to Rails 32. Significantly you can notice Grails has a much poorer worst case response time, but a superior mean response time (The mean time is the average time taken per request over all 1000 requests). This can be put down the Java threading model and the Thread pool in Tomcat at some point running out of available threads and blocking for a moment. It just reflects the differences in architecture more than anything else...[In respect to creating records] ... Grails is able to cope with 140 requests per second and has a mean average of 345ms per request compared to Rails' 35 (and a half) and 1.3 seconds per request. I believe, without having done any real profiling, the reasons for this can largely put down to Hibernate's session-based model. Each call to save() in ActiveRecord immediately persists the data whilst Hibernate batches updates up until the end...
[In respect to querying] ...the results here are much more equal as it is really reliant on database performance. Notably we can see Grails' worst case is poor down to blocking in the thread pool, but overall the mean time of 5.387ms is superior to Rails' 6.386, which illustrates why Grails' is able to deal with 8.92 requests per second as oppose to Rails' 7.65...
The article finishes by clearly stating that the authors are not Rails performance tuning wizards and are welcome to suggestions in optimizing Rails. The tests conducted were solely to inform Grails users asking for figures not as a definitive benchmark.
The Rails community has not gone quiet in regards to the benchmark data. Noted Rails developer and Mongrel user Jared Richardson commented in response:
...When your application creates a new instance or thread for every new request, it's easy for a server to get overwhelmed. Rails takes another approach. The Rails developers want you to make a conscious decision about how many resources you want an application to have ... So when you deploy a Rails application on Mongrel, you need to decide how many instances are available. This is completely different from the traditional Tomcat model, which looks something more like "spin up threads until the machine stops responding." ... If I've read the page properly, this benchmark is running against a single Mongrel instance, which is the equivalent of creating a Java singleton servlet and testing against it. Of course it's going to be quite slow ... For a real comparison, I'd try using the Apache load balancer plugin or my personal favorite Pound.
