Grails performance

[hbagchi]

In my search to migrate to newer, better and more powerful java web framework I have short-listed Grails and Seam. I feel eventually I will lean towards Grails. However, I did see some comparisons on the web showing Groovy is slower than Java in performance but that was carried out more than a year ago. I would like to know how significant that is now. Any inputs, pointers will be helpful.

[Robert Fischer]

Before discussing comparisons, let's get some perspective: unless Groovy were atrociously slow
(which it is not), the performance of your application is going to be determined more by the speed
of your HTTP and database calls than by the speed of your application.  Web servers are regularly
wildly underpowered machines and can have just fine performance: you can even run a web server on a
Commodore 64: http://58.6.118.18/

That said, there is a performance hit to using Groovy.  All dynamically typed languages on the JVM
have a performance hit (at this point, anyway).  The performance hit isn't noticeable in normal
usage, is going down, and will continue to go down as the JVM advances (1.7's invokedynamic will be
a big win for Groovy).  So while there is a performance hit, it's not enough to worry about.  The
productivity win more than makes up for it.

[Of course, one of my big soap box topics is developers getting all hung up on performance when it's
rarely actually of value to the project.  Algorithms are more important, and coping with
infrastructure is more important.  Low-level benchmarks are techno-wanking for application
developers.  And that's at best.  At worst, it's destructive and results in throwing out
higher-productivity solutions in favor of "faster" solutions.  Optimize for value to your
client/business, and that rarely means counting clock cycles.]

Having used both Grails and Seam, I strongly encourage Grails.  It is more robustly extensible, has
a better community, and seems to be building up momentum instead of losing it.  Coding Grails feels
like it is a tool created by developers for developers: Seam feels more like something foisted upon
developers from the Architects On High.  Building anything beyond the most trivial scaffolding in
either application (such as a plugin) will quickly show Grails to be the better choice.

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


hbagchi wrote:
> In my search to migrate to newer, better and more powerful java web framework
> I have short-listed Grails and Seam. I feel eventually I will lean towards
> Grails. However, I did see some comparisons on the web showing Groovy is
> slower than Java in performance but that was carried out more than a year
> ago. I would like to know how significant that is now. Any inputs, pointers
> will be helpful.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Daniel Honig]

If performance was the ONLY factor that mattered then there are definetly things that perform better.
However Grails is no slouch in performance, especially when used properly.    There are
many example of how to scale grails already in production, Sky TV being one of the most notable.

Before you go down the road of  "Groovy is not as fast as Java", I would suggest
you look into real world case studies, testimonials and metrics.   It is likely
that performance isn't the only project factor you need to consider.  I think
with a bit of research you will not only understand where grails strengths lie,
you will also come to understand your project better.

For a lot of us in the community the Rapid development capabilities,
plugins, community and ease of use were more compelling reasons to
choose grails over other frameworks, which often are not full stack
frameworks like grails.   Some other information I can offer is that
most of grails is developed in Java and Groovy is used to smartly
weave DSL's and implement other areas that are not possible with Java.

It is also important to remember that you area not locked into your grails application
with no recourse.  Since Grails is married to spring, you could design your app in a way
that it would be very easy to key services with pure Java services or data services
backed by massively scalable systems such as S3 or a NOSQL solution.

Good luck in your quest for the right framework! I hope I've been able to offer
you some decent points for consideration.

On Tue, Nov 3, 2009 at 9:59 PM, hbagchi <hbagchi@...> wrote:

In my search to migrate to newer, better and more powerful java web framework
I have short-listed Grails and Seam. I feel eventually I will lean towards
Grails. However, I did see some comparisons on the web showing Groovy is
slower than Java in performance but that was carried out more than a year
ago. I would like to know how significant that is now. Any inputs, pointers
will be helpful.
--
View this message in context: http://old.nabble.com/Grails-performance-tp26183500p26183500.html
Sent from the grails - user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[bdrhoa]

I'll just add that Grails is fun to use. I still have some things to
figure out, but over all I feel like working in Grails is what
development should be.

On Tue, Nov 3, 2009 at 7:59 PM, hbagchi <hbagchi@...> wrote:

>
> In my search to migrate to newer, better and more powerful java web framework
> I have short-listed Grails and Seam. I feel eventually I will lean towards
> Grails. However, I did see some comparisons on the web showing Groovy is
> slower than Java in performance but that was carried out more than a year
> ago. I would like to know how significant that is now. Any inputs, pointers
> will be helpful.
> --
> View this message in context: http://old.nabble.com/Grails-performance-tp26183500p26183500.html
> Sent from the grails - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
---------------------------
www.maf.org/rhoads
www.ontherhoads.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[tomas lin]

To add to what Robert and Daniel have said,

There have been significant changes in Groovy to make it faster in the
last year you might not be aware of.

In particular, the implementation of call-site caching, according to
the release notes of Groovy 1.6, claim a 150-460% improvement in
performance over previous versions of Groovy. Groovy 1.6 was released
in February, so I am not sure if the articles you mentioned take this
into account.

http://glaforge.free.fr/weblog/index.php?itemid=241

There are also speed improvements in regards to GSP rendering and
pre-compilation in Grails 1.1.1. and the upcoming 1.2.
[ http://jira.codehaus.org/browse/GRAILS-4315 /
http://grails.org/1.2-M3+Release+Notes ]

I doubt Sky TV is a standard vanilla Grails installation, but it
definitively shows you can optimise Grails to serve massive amounts of
content at high speeds.

I've used Grails since 1.0.2, and have seen a steady increase of speed
and features added to the framework.

On Wed, Nov 4, 2009 at 2:59 AM, hbagchi <hbagchi@...> wrote:

>
> In my search to migrate to newer, better and more powerful java web framework
> I have short-listed Grails and Seam. I feel eventually I will lean towards
> Grails. However, I did see some comparisons on the web showing Groovy is
> slower than Java in performance but that was carried out more than a year
> ago. I would like to know how significant that is now. Any inputs, pointers
> will be helpful.
> --
> View this message in context: http://old.nabble.com/Grails-performance-tp26183500p26183500.html
> Sent from the grails - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Michael Mellinger-3]

I don't suppose it would be possible to have a better comparison of Groovy to something else?  Simply saying that it is 150-460% better than the older version doesn't mean much.  Are you saying that it was really slow before and now it's less slow?

Scala can say that it crushes Python, for example. :-)

http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=scala&lang2=python&box=1

-Mike

On Tue, Nov 3, 2009 at 11:18 PM, Tomas Lin <tomaslin@...> wrote:

To add to what Robert and Daniel have said,

There have been significant changes in Groovy to make it faster in the
last year you might not be aware of.

In particular, the implementation of call-site caching, according to
the release notes of Groovy 1.6, claim a 150-460% improvement in
performance over previous versions of Groovy. Groovy 1.6 was released
in February, so I am not sure if the articles you mentioned take this
into account.

http://glaforge.free.fr/weblog/index.php?itemid=241

There are also speed improvements in regards to GSP rendering and
pre-compilation in Grails 1.1.1. and the upcoming 1.2.
[ http://jira.codehaus.org/browse/GRAILS-4315 /
http://grails.org/1.2-M3+Release+Notes ]

I doubt Sky TV is a standard vanilla Grails installation, but it
definitively shows you can optimise Grails to serve massive amounts of
content at high speeds.

I've used Grails since 1.0.2, and have seen a steady increase of speed
and features added to the framework.

On Wed, Nov 4, 2009 at 2:59 AM, hbagchi <hbagchi@...> wrote:
>
> In my search to migrate to newer, better and more powerful java web framework
> I have short-listed Grails and Seam. I feel eventually I will lean towards
> Grails. However, I did see some comparisons on the web showing Groovy is
> slower than Java in performance but that was carried out more than a year
> ago. I would like to know how significant that is now. Any inputs, pointers
> will be helpful.
> --
> View this message in context: http://old.nabble.com/Grails-performance-tp26183500p26183500.html
> Sent from the grails - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[tomas lin]

Yes, but Grails is not just groovy.

This set of benchmarks is recent and compares frameworks.

http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/

On Wed, Nov 4, 2009 at 5:32 AM, Michael Mellinger
<mmellinger66@...> wrote:

> I don't suppose it would be possible to have a better comparison of Groovy
> to something else?  Simply saying that it is 150-460% better than the older
> version doesn't mean much.  Are you saying that it was really slow before
> and now it's less slow?
>
> Scala can say that it crushes Python, for example. :-)
>
> http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=scala&lang2=python&box=1
>
> -Mike
>
>
>
> On Tue, Nov 3, 2009 at 11:18 PM, Tomas Lin <tomaslin@...> wrote:
>>
>> To add to what Robert and Daniel have said,
>>
>> There have been significant changes in Groovy to make it faster in the
>> last year you might not be aware of.
>>
>> In particular, the implementation of call-site caching, according to
>> the release notes of Groovy 1.6, claim a 150-460% improvement in
>> performance over previous versions of Groovy. Groovy 1.6 was released
>> in February, so I am not sure if the articles you mentioned take this
>> into account.
>>
>> http://glaforge.free.fr/weblog/index.php?itemid=241
>>
>> There are also speed improvements in regards to GSP rendering and
>> pre-compilation in Grails 1.1.1. and the upcoming 1.2.
>> [ http://jira.codehaus.org/browse/GRAILS-4315 /
>> http://grails.org/1.2-M3+Release+Notes ]
>>
>> I doubt Sky TV is a standard vanilla Grails installation, but it
>> definitively shows you can optimise Grails to serve massive amounts of
>> content at high speeds.
>>
>> I've used Grails since 1.0.2, and have seen a steady increase of speed
>> and features added to the framework.
>>
>> On Wed, Nov 4, 2009 at 2:59 AM, hbagchi <hbagchi@...> wrote:
>> >
>> > In my search to migrate to newer, better and more powerful java web
>> > framework
>> > I have short-listed Grails and Seam. I feel eventually I will lean
>> > towards
>> > Grails. However, I did see some comparisons on the web showing Groovy is
>> > slower than Java in performance but that was carried out more than a
>> > year
>> > ago. I would like to know how significant that is now. Any inputs,
>> > pointers
>> > will be helpful.
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Grails-performance-tp26183500p26183500.html
>> > Sent from the grails - user mailing list archive at Nabble.com.
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe from this list, please visit:
>> >
>> >    http://xircles.codehaus.org/manage_email
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Robert Fletcher]

On Wed, Nov 4, 2009 at 4:18 AM, Tomas Lin <tomaslin@...> wrote:
> I doubt Sky TV is a standard vanilla Grails installation, but it
> definitively shows you can optimise Grails to serve massive amounts of
> content at high speeds.
>

It's pretty vanilla: showbiz.sky.com, tv.sky.com, movies.sky.com,
sky1.sky.com and reallives.sky.com are a *single* Grails 1.1 app
deployed on jetty & postgres using 9 web nodes and 2 db nodes (CentOS
running in VMs on ESX boxes). Sure, there's a *lot* of caching going
on so relatively little of the public traffic hits the origin server
but there's also the CMS side which is part of the same app connecting
to the same DB and is used by our in-house editors.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Robert Fischer]

What approaches do you use for caching?  Any chance there's a whitepaper/blog post on the topic
somewhere?  This is a recurring conversation in production Grails apps.

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Robert Fletcher wrote:

> On Wed, Nov 4, 2009 at 4:18 AM, Tomas Lin <tomaslin@...> wrote:
>> I doubt Sky TV is a standard vanilla Grails installation, but it
>> definitively shows you can optimise Grails to serve massive amounts of
>> content at high speeds.
>>
>
> It's pretty vanilla: showbiz.sky.com, tv.sky.com, movies.sky.com,
> sky1.sky.com and reallives.sky.com are a *single* Grails 1.1 app
> deployed on jetty & postgres using 9 web nodes and 2 db nodes (CentOS
> running in VMs on ESX boxes). Sure, there's a *lot* of caching going
> on so relatively little of the public traffic hits the origin server
> but there's also the CMS side which is part of the same app connecting
> to the same DB and is used by our in-house editors.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Robert Fletcher]

Because the content as far as the public is concerned is pretty
non-interactive we have a couple of F5s sitting in front of the web
nodes caching everything for 10 minutes. For the odd thing that is
more interactive (such as the polls on the Showbiz homepage) the F5s
direct the requests straight through. The static content such as css,
js and images go via a CDN with our app being the origin server. We
use Jawr (only since recently) and make sure the caching headers on
static content are pretty agressive. Page weight is high but that's
what the client wanted, so...

On Wed, Nov 4, 2009 at 1:49 PM, Robert Fischer
<robert.fischer@...> wrote:
> What approaches do you use for caching?  Any chance there's a
> whitepaper/blog post on the topic somewhere?  This is a recurring
> conversation in production Grails apps.
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jeffrey D. Gortatowsky]

Just want to point out... in defense of the original poster (not that anyone attacked him), performance is THE VERY most important issue if you are the guy whose butt is on the line by recommending to your CTO (or partner), "Use Groovy/GRAILS". Getting to market quickly however has its benefits as well. So it's not cut and dry.

My advice to the poster is LOAD TEST your scenarios as best as possible. For sites like mine, where much of the content is variable, caching static content can get you only so far. NOSQL is my long term interest as it's almost always the @$#T&*%T@$ database(s) that are the bottleneck... but I digress...
 
So I am going subversive :) and placing GRAILS in the service layer for now, and see how that goes... my first service is ready for a Faban load test... then maybe hook into a K/V store... THEN maybe look at a public facing app...

Cheers.
---------------------------------------Jeff Gortatowsky, Fullerton, CA | Twitter: JeffGortatowsky




----- Original Message ----
From: Robert Fletcher <robert.w.fletcher@...>
To: user@...
Sent: Wed, November 4, 2009 5:59:45 AM
Subject: Re: [grails-user] Grails performance

Because the content as far as the public is concerned is pretty
non-interactive we have a couple of F5s sitting in front of the web
nodes caching everything for 10 minutes. For the odd thing that is
more interactive (such as the polls on the Showbiz homepage) the F5s
direct the requests straight through. The static content such as css,
js and images go via a CDN with our app being the origin server. We
use Jawr (only since recently) and make sure the caching headers on
static content are pretty agressive. Page weight is high but that's
what the client wanted, so...

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Robert Fischer]

What business are you in where performance "is THE VERY most important issue"?

If that's true, you should be writing Apache modules instead of CGI scripts or Grails apps.

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Jeff Gortatowsky wrote:

> Just want to point out... in defense of the original poster (not that anyone attacked him), performance is THE VERY most important issue if you are the guy whose butt is on the line by recommending to your CTO (or partner), "Use Groovy/GRAILS". Getting to market quickly however has its benefits as well. So it's not cut and dry.
>
> My advice to the poster is LOAD TEST your scenarios as best as possible. For sites like mine, where much of the content is variable, caching static content can get you only so far. NOSQL is my long term interest as it's almost always the @$#T&*%T@$ database(s) that are the bottleneck... but I digress...
>  
> So I am going subversive :) and placing GRAILS in the service layer for now, and see how that goes... my first service is ready for a Faban load test... then maybe hook into a K/V store... THEN maybe look at a public facing app...
>
> Cheers.
> ---------------------------------------Jeff Gortatowsky, Fullerton, CA | Twitter: JeffGortatowsky
>
>
>
>
> ----- Original Message ----
> From: Robert Fletcher <robert.w.fletcher@...>
> To: user@...
> Sent: Wed, November 4, 2009 5:59:45 AM
> Subject: Re: [grails-user] Grails performance
>
> Because the content as far as the public is concerned is pretty
> non-interactive we have a couple of F5s sitting in front of the web
> nodes caching everything for 10 minutes. For the odd thing that is
> more interactive (such as the polls on the Showbiz homepage) the F5s
> direct the requests straight through. The static content such as css,
> js and images go via a CDN with our app being the origin server. We
> use Jawr (only since recently) and make sure the caching headers on
> static content are pretty agressive. Page weight is high but that's
> what the client wanted, so...
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email