Grails vs Java + Spring

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Grails vs Java + Spring

nisabek
Hi all,

I know this question has been discussed mln of times, but I myself have once chosen grails for one of the projects and now we are facing some serious problems with perfromance. My assumptions is that we haven;t used it efficiently but still I am now in the middle of starting one more project and can't make a decision regarding technologies.

The application would be a simple REST service that will be saving/providing data from MongoDB database and providing some daily jobs.

Now I see 2 options: Grails or Java+Spring.

My plus for grails is that the development will go fast. with spring I might get lost with all the confiugrations. But if I look into performance it seems that 2nd options is better,

PLease help me chose:)

Thanks in advance.

Regards,
Nune
Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

Miles Burton-2
Well the age old saying that Grails is just a wrapper around Spring is worth remembering (not quite that simple though).

I'd recommend playing around with the Grails Mongo Plugin before you make a decision. You may also find the request.withFormat and withFormat closures very useful for playing around with webservices. The quartz plugin could also be handy for scheduling if you need to do that. 

On Fri, Jun 15, 2012 at 6:54 AM, nisabek <[hidden email]> wrote:
Hi all,

I know this question has been discussed mln of times, but I myself have once
chosen grails for one of the projects and now we are facing some serious
problems with perfromance. My assumptions is that we haven;t used it
efficiently but still I am now in the middle of starting one more project
and can't make a decision regarding technologies.

The application would be a simple REST service that will be saving/providing
data from MongoDB database and providing some daily jobs.

Now I see 2 options: Grails or Java+Spring.

My plus for grails is that the development will go fast. with spring I might
get lost with all the confiugrations. But if I look into performance it
seems that 2nd options is better,

PLease help me chose:)

Thanks in advance.

Regards,
Nune

--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-vs-Java-Spring-tp4630161.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



Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

a.shneyderman
In reply to this post by nisabek
On Fri, Jun 15, 2012 at 7:54 AM, nisabek <[hidden email]> wrote:
> The application would be a simple REST service that will be saving/providing
> data from MongoDB database and providing some daily jobs.

If I were you I'd take a look at dropwizard for this. I like grails
but it is a lot better
suited for UI apps. It adds a lot of baggage to be used for something as simple
as REST service.

Cheers,
Alex.

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

John Fletcher-3
In reply to this post by nisabek
2012/6/15 nisabek
> chosen grails for one of the projects and now we are facing some serious
> problems with perfromance. My assumptions is that we haven;t used it

On the whole I see very few messages on this list where people are
battling with serious performance problems. You need to figure out
exactly which part of your application is causing the problems, it may
not be Grails in and of itself. A basic internet search should reveal
some good resources to help you get started in profiling the
application - on a simple level this shouldn't take too long.

>
> The application would be a simple REST service that will be saving/providing
> data from MongoDB database and providing some daily jobs.
>
> Now I see 2 options: Grails or Java+Spring.
>
> My plus for grails is that the development will go fast. with spring I might
> get lost with all the confiugrations. But if I look into performance it
> seems that 2nd options is better,

If you want to use Spring directly, use Spring Roo. This helps avoid
the configuration headaches and get things going quickly.
Nevertheless, from the basic description you have given of the
application, I would say that there would probably be no discernable
difference in performance between the two technologies. If I were you
I would choose Grails simply to have continuity between your
applications. Your developers only need to understand one technology
to understand both applications.

John

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

RE: Grails vs Java + Spring

Ryan Vanderwerf
In reply to this post by nisabek
I assume you've gone over the GORM Gotcha's article that Peter wrote, and Burt's talks about GORM performance?

http://blog.springsource.org/2010/06/23/gorm-gotchas-part-1/ (There are parts 2 and 3 too)
http://www.infoq.com/presentations/GORM-Performance

I'd make sure those are taken to heart if you are having issues and those are things to keep in mind while coding for sure. If you follow those rules, I don't see why Grails could be much slower than a java+spring+hibernate implementation.


Ryan

________
From: nisabek [[hidden email]]
Sent: Friday, June 15, 2012 12:54 AM
To: [hidden email]
Subject: [grails-user] Grails vs Java + Spring

Hi all,

I know this question has been discussed mln of times, but I myself have once
chosen grails for one of the projects and now we are facing some serious
problems with perfromance. My assumptions is that we haven;t used it
efficiently but still I am now in the middle of starting one more project
and can't make a decision regarding technologies.

The application would be a simple REST service that will be saving/providing
data from MongoDB database and providing some daily jobs.

Now I see 2 options: Grails or Java+Spring.

My plus for grails is that the development will go fast. with spring I might
get lost with all the confiugrations. But if I look into performance it
seems that 2nd options is better,

PLease help me chose:)

Thanks in advance.

Regards,
Nune

--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-vs-Java-Spring-tp4630161.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


Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

Roberto Guerra
+1 on Ryan's comments. 
Any technology not used properly will have issues with performance. You will have some issue or another popping up (if not performance, development time, or integration or .... or ... or ...) 
It is important to decide based on your needs and strengths instead of saying : oh, this thing is crap, that other thing is useless because I couldn't get it to run, oh, and annotations suck, oh and this thing also sucks... 

My first impulse when developing an app is to always go for grails (for the time being). I can focus on the business processes and then worry about performance later on. Burt's book has some excellent information on how to get around some of the possible performance hits and if the app is a critical app, then it should be on a serious server (lots of RAM and lots of processing power and really good storage). It is easier to improve performance by adding better hardware than impulsively delving into code.

Just my 2 cents.

On Fri, Jun 15, 2012 at 7:59 AM, Ryan Vanderwerf <[hidden email]> wrote:
I assume you've gone over the GORM Gotcha's article that Peter wrote, and Burt's talks about GORM performance?

http://blog.springsource.org/2010/06/23/gorm-gotchas-part-1/ (There are parts 2 and 3 too)
http://www.infoq.com/presentations/GORM-Performance

I'd make sure those are taken to heart if you are having issues and those are things to keep in mind while coding for sure. If you follow those rules, I don't see why Grails could be much slower than a java+spring+hibernate implementation.


Ryan

________
From: nisabek [[hidden email]]
Sent: Friday, June 15, 2012 12:54 AM
To: [hidden email]
Subject: [grails-user] Grails vs Java + Spring

Hi all,

I know this question has been discussed mln of times, but I myself have once
chosen grails for one of the projects and now we are facing some serious
problems with perfromance. My assumptions is that we haven;t used it
efficiently but still I am now in the middle of starting one more project
and can't make a decision regarding technologies.

The application would be a simple REST service that will be saving/providing
data from MongoDB database and providing some daily jobs.

Now I see 2 options: Grails or Java+Spring.

My plus for grails is that the development will go fast. with spring I might
get lost with all the confiugrations. But if I look into performance it
seems that 2nd options is better,

PLease help me chose:)

Thanks in advance.

Regards,
Nune

--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-vs-Java-Spring-tp4630161.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





--
The Journey Is The Reward.
Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

Dave Crane-7
Yes, it's possible to write poorly-performing code using any technology. Specific technologies will have specific performance issues. At Historic Futures, we're using Grails to deliver REST APIs to customers with fairly high throughput - it can be done.

Groovy has traditionally had performance issues around the MOP (the stuff that figures out whether a property is a property or a getter/setter, or should be passed on to the methodMissing method, etc.), so code that relies heavily on the MOP can perform poorly - that's the price of the flexibility of the language. Performance of the MOP has improved over the last few years,I believe, but it's always going to be something of an issue.

For a typical REST-like app that's returning data rather than GSP-generated HTML, your code is doing two things:
1. assemble request params and query the domain model
2. output the domain model, most commonly using an XML builder or JSON builder 


The builder pattern used by step 2 makes very heavy use of the methodMissing method and the MOP (decent description of how it works here if you're interested: http://www.artima.com/weblogs/viewpost.jsp?thread=291467). From some very rough benchmarking that my colleagues did on a couple of poorly-performing pages, this can be a source of performance issues. This is anecdotal, and we weren't using Grails 2.0 when we did these benchmarks, so take what I say with a pinch of salt :)

I'd suggest sticking a few logging statements in your code to see if the slowness you are seeing comes from querying the database, or assembling the output data. If it is the builder code that's giving you problems, you could try replacing that with a bit of java code to serialise on an output format of your choice, and still enjoy all the benefits of GORM, routing & so on. At any rate, you'll have a clearer idea of where the problems lie.

Be aware too that a builder could easily reference associations or properties in your domain model that weren't eagerly fetched, and you'll end up with an N+1 problem, but this isn't peculiar to Grails or Groovy.

I'd be interested to know if anyone else has come across the builders as a performance problem in Grails.

HTH

Dave

On 15 June 2012 15:07, Roberto Guerra <[hidden email]> wrote:
+1 on Ryan's comments. 
Any technology not used properly will have issues with performance. You will have some issue or another popping up (if not performance, development time, or integration or .... or ... or ...) 
It is important to decide based on your needs and strengths instead of saying : oh, this thing is crap, that other thing is useless because I couldn't get it to run, oh, and annotations suck, oh and this thing also sucks... 

My first impulse when developing an app is to always go for grails (for the time being). I can focus on the business processes and then worry about performance later on. Burt's book has some excellent information on how to get around some of the possible performance hits and if the app is a critical app, then it should be on a serious server (lots of RAM and lots of processing power and really good storage). It is easier to improve performance by adding better hardware than impulsively delving into code.

Just my 2 cents.


On Fri, Jun 15, 2012 at 7:59 AM, Ryan Vanderwerf <[hidden email]> wrote:
I assume you've gone over the GORM Gotcha's article that Peter wrote, and Burt's talks about GORM performance?

http://blog.springsource.org/2010/06/23/gorm-gotchas-part-1/ (There are parts 2 and 3 too)
http://www.infoq.com/presentations/GORM-Performance

I'd make sure those are taken to heart if you are having issues and those are things to keep in mind while coding for sure. If you follow those rules, I don't see why Grails could be much slower than a java+spring+hibernate implementation.


Ryan

________
From: nisabek [[hidden email]]
Sent: Friday, June 15, 2012 12:54 AM
To: [hidden email]
Subject: [grails-user] Grails vs Java + Spring

Hi all,

I know this question has been discussed mln of times, but I myself have once
chosen grails for one of the projects and now we are facing some serious
problems with perfromance. My assumptions is that we haven;t used it
efficiently but still I am now in the middle of starting one more project
and can't make a decision regarding technologies.

The application would be a simple REST service that will be saving/providing
data from MongoDB database and providing some daily jobs.

Now I see 2 options: Grails or Java+Spring.

My plus for grails is that the development will go fast. with spring I might
get lost with all the confiugrations. But if I look into performance it
seems that 2nd options is better,

PLease help me chose:)

Thanks in advance.

Regards,
Nune

--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-vs-Java-Spring-tp4630161.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





--
The Journey Is The Reward.



--
Dave Crane
Technical Lead/Architect
Historic Futures Ltd.
W: http://historicfutures.com

This email, including any attachments, is confidential. If you receive this message in error please inform the sender and delete it. Historic Futures reserves the right to monitor or record emails.

Historic Futures Ltd. Registered Office: Carpenters' Workshop, Blenheim Palace Sawmills, Swan Lane, Combe, Oxfordshire, OX29 8ET. Registered in England No: 04693909.

Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

Lori Sun
In reply to this post by nisabek
Hi Nune,

Maybe you could use both of them, they do could work together smoothly and easily, Controller/UrlMapping are for REST, the backend service just using pure java/high performance database access and existed spring IOC container.

Actually after >grails prod war,  grails will generate standard java web application, so I don't think it will get so big performance issue. maybe you are constructing a huge projetc  

Below several plugins may increase performance of web app, holp it helpful for you.  
        runtime ":zipped-resources:1.0"
        runtime ":cached-resources:1.0"
        runtime ":yui-minify-resources:0.1.5"
        runtime ":cache-headers:1.1.5"

Thanks,
Lori
Java/groovy/grails/Extjs/GXT/GEMFIRE/MongoDB
Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

antony
This question is tiring so I'll just summarise what I've learned
writing huge, huge grails applications for the last 3 years.

1. Grails is not as performant as Spring+Java, but unless you're
writing highly transactional latency-sensitive applications for
trading systems etc, it is negligible.
2. Grails is massively more performant for developers, and by that I
mean that it is a framework designed for developer productivity and
happiness, not for performance.
3. 99% of the time, it's YOU, not the framework - figure out what
you're doing wrong and do it better.
4. Grails is one of those things which only experience can solve, not
everything is obvious (most things are), but there are caveats and
workarounds which take experience - it's not a silver bullet.
5. I've written systems which handle millions of users per day in
Grails. It's production ready. I've not run into any walls yet (which
I did with Rails, years ago).

If you take the time to work out your problems and learn from them,
Grails can do anything you want of it, but like anything, there is a
learning curve.

Cheers,
Antony

On 15 June 2012 17:31, Lori Sun <[hidden email]> wrote:

> Hi Nune,
>
> Maybe you could use both of them, they do could work together smoothly and
> easily, Controller/UrlMapping are for REST, the backend service just using
> pure java/high performance database access and existed spring IOC container.
>
> Actually after >grails prod war,  grails will generate standard java web
> application, so I don't think it will get so big performance issue. maybe
> you are constructing a huge projetc
>
> Below several plugins may increase performance of web app, holp it helpful
> for you.
>        runtime ":zipped-resources:1.0"
>        runtime ":cached-resources:1.0"
>        runtime ":yui-minify-resources:0.1.5"
>        runtime ":cache-headers:1.1.5"
>
> Thanks,
> Lori
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Grails-vs-Java-Spring-tp4630161p4630198.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
>
>



--
________________________________
ꜽ . antony jones . http://www.enzy.org

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

Lori Sun
Agree~!  I'm a fresh man in Grails world. Grails already brought me productivity benefit. so I like it very much, and will keep learning it on spare time. My core job is gxt/gwt  recently.

Thanks,
Lori
Java/groovy/grails/Extjs/GXT/GEMFIRE/MongoDB
Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

Dave Crane-7
In reply to this post by Lori Sun
That doesn't necessarily hold, Lori. A war file is just a standard way of zipping up a lot of executable java code and hooking it up to some low-level servlet APIs. Performance will depend on what the executable code inside the file is doing - I could write a simple servlet that spawned a few hundred threads, tried to write a few GB of rubbish to disk, and so on - being in awar file wouldn't stop it from performing terribly.

When Groovy files are compiled to java bytecode, the code still talks to the Groovy runtime API - the MOP and all that - and so compiled code still sees the trade-off between performance and flexibility as a result. As other posters have noted on this thread, that drop in performance is generally not problematic, but with my pedant's hat on, I couldn't resist pointing out that it's still there :)

HTH

Dave

On 15 June 2012 17:31, Lori Sun <[hidden email]> wrote:
Actually after >grails prod war,  grails will generate standard java web
application, so I don't think it will get so big performance issue. 

--
Dave Crane
Technical Lead/Architect
Historic Futures Ltd.
W: http://historicfutures.com

This email, including any attachments, is confidential. If you receive this message in error please inform the sender and delete it. Historic Futures reserves the right to monitor or record emails.

Historic Futures Ltd. Registered Office: Carpenters' Workshop, Blenheim Palace Sawmills, Swan Lane, Combe, Oxfordshire, OX29 8ET. Registered in England No: 04693909.

Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

Konstantyn Smirnov
In reply to this post by nisabek
Years ago I built using Grails 1.something a simple RESTful suggestion service with the lucene search engine as a backend. The later one contained 10 different physical indizies each with up to 3 mio documents and 300 MB size, and once a day each index gets updated.
The application has been running since then flawlessly with 0 maintenance costs (parallel to the couple of other apps in the same tomcat), providing the response times within 20-60 ms.

So, yes, I would pick grails blindly over any other framework :)
Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

ideasculptor


On Wed, Jun 20, 2012 at 1:26 AM, Konstantyn Smirnov <[hidden email]> wrote:
Years ago I built using Grails 1.something a simple RESTful suggestion
service with the lucene search engine as a backend. The later one contained
10 different physical indizies each with up to 3 mio documents and 300 MB
size, and once a day each index gets updated.
The application has been running since then flawlessly with 0 maintenance
costs (parallel to the couple of other apps in the same tomcat), providing
the response times within 20-60 ms.

So, yes, I would pick grails blindly over any other framework :)


Choosing anything blindly isn't likely to work out well in the long run.  That particular solution is a great candidate for a relatively low performance framework because the vast majority of the work involved in servicing a request is in lucene, not in the web framework.  Serve up pages with lots of logic in templates and controllers with numerous queries against a database and you may find that grails contributes a whole lot more to the overhead of satisfying a request, at which point a more efficient framework (or ditching a framework entirely for hand coded queries and http handling) may well get you far better results.  It depends entirely on what your app's requirements are. If you absolutely, positively must spit back a response in 20ms or less, handle a huge number of requests in parallel on minimal hardware resources, and developer productivity isn't a concern, a framework like grails may be completely unusable.  In general, for enterprise-style apps which don't tend to have large numbers of users accessing in parallel, which have limited developer resources and short dev schedules, it is easy to justify the use of grails.  Faster database and web server hardware is far cheaper than developer salaries when your app has hundreds or thousands of users.  It's a different story when you are building to handle millions of users. The incremental cost of a hardware upgrade is far, far higher in the latter case. 


Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

antony
Grails isn't low performance, it can easily, easily handle millions of
users - our current count is 17 million, and it can handle thousands
in parallel without a problem.

I'm not sure what you're suggesting can handle such users better -
Java is a heavy load for any server, but Grails isn't a huge
contributor to that load.

>> If you absolutely, positively must spit back a response in 20ms or less, handle a huge number of requests in parallel on minimal hardware resources, and developer productivity isn't a concern

It's not just productivity, it's developer happiness. If developer
productivity and happiness aren't a concern for you, there is
something much more deep rooted wrong with your business.

>> Faster database and web server hardware is far cheaper than developer salaries when your app has hundreds or thousands of users.

You should look to scale horizontally, not vertically. If you're
scaling vertically your costs will escalate very quickly and you will
hit a hard ceiling very fast. It's probably not worth the cost of
optimising your software to attempt to combat or delay this
eventuality.

Cheers,
Antony

On 20 June 2012 09:51, Samuel Gendler <[hidden email]> wrote:

>
>
> On Wed, Jun 20, 2012 at 1:26 AM, Konstantyn Smirnov <[hidden email]>
> wrote:
>>
>> Years ago I built using Grails 1.something a simple RESTful suggestion
>> service with the lucene search engine as a backend. The later one
>> contained
>> 10 different physical indizies each with up to 3 mio documents and 300 MB
>> size, and once a day each index gets updated.
>> The application has been running since then flawlessly with 0 maintenance
>> costs (parallel to the couple of other apps in the same tomcat), providing
>> the response times within 20-60 ms.
>>
>> So, yes, I would pick grails blindly over any other framework :)
>>
>
> Choosing anything blindly isn't likely to work out well in the long run.
>  That particular solution is a great candidate for a relatively low
> performance framework because the vast majority of the work involved in
> servicing a request is in lucene, not in the web framework.  Serve up pages
> with lots of logic in templates and controllers with numerous queries
> against a database and you may find that grails contributes a whole lot more
> to the overhead of satisfying a request, at which point a more efficient
> framework (or ditching a framework entirely for hand coded queries and http
> handling) may well get you far better results.  It depends entirely on what
> your app's requirements are. If you absolutely, positively must spit back a
> response in 20ms or less, handle a huge number of requests in parallel on
> minimal hardware resources, and developer productivity isn't a concern, a
> framework like grails may be completely unusable.  In general, for
> enterprise-style apps which don't tend to have large numbers of users
> accessing in parallel, which have limited developer resources and short dev
> schedules, it is easy to justify the use of grails.  Faster database and web
> server hardware is far cheaper than developer salaries when your app has
> hundreds or thousands of users.  It's a different story when you are
> building to handle millions of users. The incremental cost of a hardware
> upgrade is far, far higher in the latter case.
>
>



--
________________________________
ꜽ . antony jones . http://www.enzy.org

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

zyro
slightly off topic but antony, do you think you could share some
experience regarding horizontal scaling of a grails-app?

thinking of a bit of blogging or sth :)

ofc if someone else can point to interesting resources on that topic id
be happy to get to know those, too.

zyro

-------- Original Message  --------
Subject: Re: [grails-user] Re: Grails vs Java + Spring
From: Antony Jones <[hidden email]>
To: [hidden email]
Date: Wed, 20 Jun 2012 13:22:50 +0100

> Grails isn't low performance, it can easily, easily handle millions of
> users - our current count is 17 million, and it can handle thousands
> in parallel without a problem.
>
> I'm not sure what you're suggesting can handle such users better -
> Java is a heavy load for any server, but Grails isn't a huge
> contributor to that load.
>
>>> If you absolutely, positively must spit back a response in 20ms or less, handle a huge number of requests in parallel on minimal hardware resources, and developer productivity isn't a concern
>
> It's not just productivity, it's developer happiness. If developer
> productivity and happiness aren't a concern for you, there is
> something much more deep rooted wrong with your business.
>
>>> Faster database and web server hardware is far cheaper than developer salaries when your app has hundreds or thousands of users.
>
> You should look to scale horizontally, not vertically. If you're
> scaling vertically your costs will escalate very quickly and you will
> hit a hard ceiling very fast. It's probably not worth the cost of
> optimising your software to attempt to combat or delay this
> eventuality.
>
> Cheers,
> Antony
>
> On 20 June 2012 09:51, Samuel Gendler <[hidden email]> wrote:
>>
>>
>> On Wed, Jun 20, 2012 at 1:26 AM, Konstantyn Smirnov <[hidden email]>
>> wrote:
>>>
>>> Years ago I built using Grails 1.something a simple RESTful suggestion
>>> service with the lucene search engine as a backend. The later one
>>> contained
>>> 10 different physical indizies each with up to 3 mio documents and 300 MB
>>> size, and once a day each index gets updated.
>>> The application has been running since then flawlessly with 0 maintenance
>>> costs (parallel to the couple of other apps in the same tomcat), providing
>>> the response times within 20-60 ms.
>>>
>>> So, yes, I would pick grails blindly over any other framework :)
>>>
>>
>> Choosing anything blindly isn't likely to work out well in the long run.
>>  That particular solution is a great candidate for a relatively low
>> performance framework because the vast majority of the work involved in
>> servicing a request is in lucene, not in the web framework.  Serve up pages
>> with lots of logic in templates and controllers with numerous queries
>> against a database and you may find that grails contributes a whole lot more
>> to the overhead of satisfying a request, at which point a more efficient
>> framework (or ditching a framework entirely for hand coded queries and http
>> handling) may well get you far better results.  It depends entirely on what
>> your app's requirements are. If you absolutely, positively must spit back a
>> response in 20ms or less, handle a huge number of requests in parallel on
>> minimal hardware resources, and developer productivity isn't a concern, a
>> framework like grails may be completely unusable.  In general, for
>> enterprise-style apps which don't tend to have large numbers of users
>> accessing in parallel, which have limited developer resources and short dev
>> schedules, it is easy to justify the use of grails.  Faster database and web
>> server hardware is far cheaper than developer salaries when your app has
>> hundreds or thousands of users.  It's a different story when you are
>> building to handle millions of users. The incremental cost of a hardware
>> upgrade is far, far higher in the latter case.
>>
>>
>
>
>


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

Nathan Wells
Horizontal scaling if you have a stateless server is easy. This is why your server should be stateless :).

Obviously this may not always be practical. But don't consider it automatically impractical. Stateless servers simplify a lot of the problems of application development, including horizontal scaling. Any discussion of horizontally scaled application should start with an honest assessment of the effort to make the server stateless.

Nathan Wells


On Wed, Jun 20, 2012 at 12:06 PM, zyro <[hidden email]> wrote:
slightly off topic but antony, do you think you could share some
experience regarding horizontal scaling of a grails-app?

thinking of a bit of blogging or sth :)

ofc if someone else can point to interesting resources on that topic id
be happy to get to know those, too.

zyro

-------- Original Message  --------
Subject: Re: [grails-user] Re: Grails vs Java + Spring
From: Antony Jones <[hidden email]>
To: [hidden email]
Date: Wed, 20 Jun 2012 13:22:50 +0100

> Grails isn't low performance, it can easily, easily handle millions of
> users - our current count is 17 million, and it can handle thousands
> in parallel without a problem.
>
> I'm not sure what you're suggesting can handle such users better -
> Java is a heavy load for any server, but Grails isn't a huge
> contributor to that load.
>
>>> If you absolutely, positively must spit back a response in 20ms or less, handle a huge number of requests in parallel on minimal hardware resources, and developer productivity isn't a concern
>
> It's not just productivity, it's developer happiness. If developer
> productivity and happiness aren't a concern for you, there is
> something much more deep rooted wrong with your business.
>
>>> Faster database and web server hardware is far cheaper than developer salaries when your app has hundreds or thousands of users.
>
> You should look to scale horizontally, not vertically. If you're
> scaling vertically your costs will escalate very quickly and you will
> hit a hard ceiling very fast. It's probably not worth the cost of
> optimising your software to attempt to combat or delay this
> eventuality.
>
> Cheers,
> Antony
>
> On 20 June 2012 09:51, Samuel Gendler <[hidden email]> wrote:
>>
>>
>> On Wed, Jun 20, 2012 at 1:26 AM, Konstantyn Smirnov <[hidden email]>
>> wrote:
>>>
>>> Years ago I built using Grails 1.something a simple RESTful suggestion
>>> service with the lucene search engine as a backend. The later one
>>> contained
>>> 10 different physical indizies each with up to 3 mio documents and 300 MB
>>> size, and once a day each index gets updated.
>>> The application has been running since then flawlessly with 0 maintenance
>>> costs (parallel to the couple of other apps in the same tomcat), providing
>>> the response times within 20-60 ms.
>>>
>>> So, yes, I would pick grails blindly over any other framework :)
>>>
>>
>> Choosing anything blindly isn't likely to work out well in the long run.
>>  That particular solution is a great candidate for a relatively low
>> performance framework because the vast majority of the work involved in
>> servicing a request is in lucene, not in the web framework.  Serve up pages
>> with lots of logic in templates and controllers with numerous queries
>> against a database and you may find that grails contributes a whole lot more
>> to the overhead of satisfying a request, at which point a more efficient
>> framework (or ditching a framework entirely for hand coded queries and http
>> handling) may well get you far better results.  It depends entirely on what
>> your app's requirements are. If you absolutely, positively must spit back a
>> response in 20ms or less, handle a huge number of requests in parallel on
>> minimal hardware resources, and developer productivity isn't a concern, a
>> framework like grails may be completely unusable.  In general, for
>> enterprise-style apps which don't tend to have large numbers of users
>> accessing in parallel, which have limited developer resources and short dev
>> schedules, it is easy to justify the use of grails.  Faster database and web
>> server hardware is far cheaper than developer salaries when your app has
>> hundreds or thousands of users.  It's a different story when you are
>> building to handle millions of users. The incremental cost of a hardware
>> upgrade is far, far higher in the latter case.
>>
>>
>
>
>


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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

ideasculptor
In reply to this post by antony


On Wed, Jun 20, 2012 at 5:22 AM, Antony Jones <[hidden email]> wrote:
Grails isn't low performance, it can easily, easily handle millions of
users - our current count is 17 million, and it can handle thousands
in parallel without a problem.

I'm not sure what you're suggesting can handle such users better -
Java is a heavy load for any server, but Grails isn't a huge
contributor to that load.

Grails can be a very large contributor to that load, depending entirely on the nature of the application.  To make an argument either way without a larger context doesn't make much sense, but it is trivially easy to postulate a context in which grails will reach performance limits that other development environments will not.  In general, there's not a huge degree of difference between interpreted, loosely typed languages.  But you're fooling yourself if you think that there isn't a huge degree of difference between writing strongly typed, compiled code and dealing with groovy, php, python, or ruby.
 

>> If you absolutely, positively must spit back a response in 20ms or less, handle a huge number of requests in parallel on minimal hardware resources, and developer productivity isn't a concern

It's not just productivity, it's developer happiness. If developer
productivity and happiness aren't a concern for you, there is
something much more deep rooted wrong with your business.

If your developers' happiness is rooted in the language and frameworks they use rather than the nature of work, quality of the product, and quality of the team, then 'there is something much more deep rooted wrong with your business.' Developer productivity is important - no one wants to feel like they are wasting their time - but productivity has to be weighed against results.  If a small team can push out agile releases of a product that requires very large infrastructure to support, but you need a bigger dev team or a slightly longer release cycle to push out equivalent functionality on a fraction of the hardware infrastructure, then that can still be a net productivity gain.  Yes, with small enterprise user bases, particularly expert users who tend to be more tolerant of latency than drive-by web users who have no experience with what you are offering and make judgements based on very superficial experiences, you needn't care overly much about the difference between a 20ms render time and a 300ms render time.  When you are serving up display ads on some of the most highly trafficked websites on the internet, that difference can mean hundreds or even thousands of servers, hundreds of megawatts of power over a year, and billions of ad impressions not delivered because the user surfed away before giving your ad time to load.  The same goes for serving up actual content on large, highly trafficked websites.

 

>> Faster database and web server hardware is far cheaper than developer salaries when your app has hundreds or thousands of users.

You should look to scale horizontally, not vertically. If you're
scaling vertically your costs will escalate very quickly and you will
hit a hard ceiling very fast. It's probably not worth the cost of
optimising your software to attempt to combat or delay this
eventuality.

That should have read hundreds or thousands of servers, not users.  At some point, you do have to scale vertically.  If you've already got 50 servers in play and all fairly well utilized, a feature that will double the latency of a request will force you to buy 50 new servers to keep your utilizations levels the same.  That has real budgetary consequences - not just for hardware purchases, but also data center real estate, IT personnel and monitoring resources, hardware failure frequency, etc.  Now scale that up by an order of magnitude or two and it starts to get really relevant.  Compute resources are cheap.  Data center real estate, electrical power, and IT staffing start to become a real issue when you don't have sufficient vertical scalability. This is why we see cloud computing providers investing in huge data centers with the ability to generate their own power, building completely custom hardware and cooling technologies, etc. You don't suppose there's a reason why facebook runs a hacked version of php, on a hacked kernel, accessing images via a custom filesystem that can more rapidly address bytes in storage?  They were forced into such remedies because there is a maximum latency that end-users are willing to tolerate and because it is simply too expensive to scale only horizontally when traffic volumes get very high - and no, you don't have to be facebook for such limits to become relevant.  I'm not claiming its the norm - especially for enterprise development at smaller companies (and even plenty of big ones) - but it very much does exist and for plenty of companies.  

Some of grails' limits are imposed by the language - it's simply not as fast to deal with interpretation and dynamic types, missing methods, etc. And some are imposed by architecture - ORM will never perform as well as custom written sql that is tuned for each specific case.  There were tradeoffs made in the adoption of those technologies for grails. For the vast majority of web development, those tradeoffs make abundant sense.  But to imply that they are appropriate in every case is very naive.

Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

Roberto Guerra
I notice a trend:
People use to say C++ was too slow.
When Java appeared, for years people would say its slower than C++ and you shouldn't use it for 'real work'. It would never perform.
Now, people say these new languages(ruby, groovy, scala, etc) are slow, and it will never be as fast as Java. If you want performance stick to Java. 

Hmmm. Just saying.

On Wed, Jun 20, 2012 at 2:55 PM, Samuel Gendler <[hidden email]> wrote:


On Wed, Jun 20, 2012 at 5:22 AM, Antony Jones <[hidden email]> wrote:
Grails isn't low performance, it can easily, easily handle millions of
users - our current count is 17 million, and it can handle thousands
in parallel without a problem.

I'm not sure what you're suggesting can handle such users better -
Java is a heavy load for any server, but Grails isn't a huge
contributor to that load.

Grails can be a very large contributor to that load, depending entirely on the nature of the application.  To make an argument either way without a larger context doesn't make much sense, but it is trivially easy to postulate a context in which grails will reach performance limits that other development environments will not.  In general, there's not a huge degree of difference between interpreted, loosely typed languages.  But you're fooling yourself if you think that there isn't a huge degree of difference between writing strongly typed, compiled code and dealing with groovy, php, python, or ruby.
 

>> If you absolutely, positively must spit back a response in 20ms or less, handle a huge number of requests in parallel on minimal hardware resources, and developer productivity isn't a concern

It's not just productivity, it's developer happiness. If developer
productivity and happiness aren't a concern for you, there is
something much more deep rooted wrong with your business.

If your developers' happiness is rooted in the language and frameworks they use rather than the nature of work, quality of the product, and quality of the team, then 'there is something much more deep rooted wrong with your business.' Developer productivity is important - no one wants to feel like they are wasting their time - but productivity has to be weighed against results.  If a small team can push out agile releases of a product that requires very large infrastructure to support, but you need a bigger dev team or a slightly longer release cycle to push out equivalent functionality on a fraction of the hardware infrastructure, then that can still be a net productivity gain.  Yes, with small enterprise user bases, particularly expert users who tend to be more tolerant of latency than drive-by web users who have no experience with what you are offering and make judgements based on very superficial experiences, you needn't care overly much about the difference between a 20ms render time and a 300ms render time.  When you are serving up display ads on some of the most highly trafficked websites on the internet, that difference can mean hundreds or even thousands of servers, hundreds of megawatts of power over a year, and billions of ad impressions not delivered because the user surfed away before giving your ad time to load.  The same goes for serving up actual content on large, highly trafficked websites.

 

>> Faster database and web server hardware is far cheaper than developer salaries when your app has hundreds or thousands of users.

You should look to scale horizontally, not vertically. If you're
scaling vertically your costs will escalate very quickly and you will
hit a hard ceiling very fast. It's probably not worth the cost of
optimising your software to attempt to combat or delay this
eventuality.

That should have read hundreds or thousands of servers, not users.  At some point, you do have to scale vertically.  If you've already got 50 servers in play and all fairly well utilized, a feature that will double the latency of a request will force you to buy 50 new servers to keep your utilizations levels the same.  That has real budgetary consequences - not just for hardware purchases, but also data center real estate, IT personnel and monitoring resources, hardware failure frequency, etc.  Now scale that up by an order of magnitude or two and it starts to get really relevant.  Compute resources are cheap.  Data center real estate, electrical power, and IT staffing start to become a real issue when you don't have sufficient vertical scalability. This is why we see cloud computing providers investing in huge data centers with the ability to generate their own power, building completely custom hardware and cooling technologies, etc. You don't suppose there's a reason why facebook runs a hacked version of php, on a hacked kernel, accessing images via a custom filesystem that can more rapidly address bytes in storage?  They were forced into such remedies because there is a maximum latency that end-users are willing to tolerate and because it is simply too expensive to scale only horizontally when traffic volumes get very high - and no, you don't have to be facebook for such limits to become relevant.  I'm not claiming its the norm - especially for enterprise development at smaller companies (and even plenty of big ones) - but it very much does exist and for plenty of companies.  

Some of grails' limits are imposed by the language - it's simply not as fast to deal with interpretation and dynamic types, missing methods, etc. And some are imposed by architecture - ORM will never perform as well as custom written sql that is tuned for each specific case.  There were tradeoffs made in the adoption of those technologies for grails. For the vast majority of web development, those tradeoffs make abundant sense.  But to imply that they are appropriate in every case is very naive.




--
The Journey Is The Reward.
Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

ideasculptor


On Wed, Jun 20, 2012 at 2:04 PM, Roberto Guerra <[hidden email]> wrote:
I notice a trend:
People use to say C++ was too slow.
When Java appeared, for years people would say its slower than C++ and you shouldn't use it for 'real work'. It would never perform.
Now, people say these new languages(ruby, groovy, scala, etc) are slow, and it will never be as fast as Java. If you want performance stick to Java. 

Hmmm. Just saying.

And C++ is still slower than C.  And Java is still slower than C++. And for the record, when people claimed java was slow, it was REALLY slow.  Virtual machines got MUCH faster. Arguing that people should have used java for performance applications even back when it was dreadfully slow, because it would eventually get faster, is missing the point.  If I need performance now, I need to use technology that is fast now.  And C, C++, and Java are still all strongly-typed, compiled languages.  In fact, when java was slow, it was because it was interpreted in the virtual machine.  So comparing the negligible performance differences between those very similar languages and trying to infer anything about the performance differences between those languages and interpreted, loosely typed languages like groovy or ruby doesn't make a whole lot of sense.  Python has been around for 15 years.  It was very slow compared to strongly-typed, compiled languages when it was initially released and it is still very slow compared to strongly-typed, compiled languages today.  Because the dynamic nature of the language itself is what slows it down.  Java got faster because it isn't dynamic and JIT compiling allowed the virtual machine to execute with performance very close to native code.  Write a bunch of java code that relies heavily on reflection and dynamically generated proxies to deliver the kind of dynamic experience that you get with groovy and you get performance not far off of groovy's, even in the latest java releases. While hardware improvements can make much of the difference in instruction execution performance something of a moot point _over_time_ (as was seen through the 90s and the first half of the last decade), we also haven't seen significant gains in instruction execution performance in recent years.  More cores, yes.  Faster cores, not so much.  With the processing of a single request limited to a single thread/core, that minimum latency problem doesn't have an easy fix if the latency is a result of performance of the framework itself rather than blocking on i/o or algorithmic inefficiencies.  Will the groovy interpreter get better over time?  Inevitably.  But it isn't going to equal the performance of a compiled, strongly typed language.  Dynamic languages very intentionally make a compromise between execution performance and developer productivity - a compromise that isn't always appropriate to make.  There's a reason why projects that need super-high performance still drop back to C or assembler for the most crucial parts of the code.  Fortunately for all of us, most web development doesn't require super-high performance.  But that doesn't make it always not relevant. 

Performance always has and always will matter, and some measures of performance simply cannot be improved with horizontal scalability.  When those measures are important, vertical scalability is the only way to get it, and grails (or any other general purpose framework) can easily become a liability in that context.  That's not a knock against grails.  That's not what grails is intended to be.  Grails does what it does incredibly well.  But it was never designed to be a solution to serving up dynamically generated content in the least possible time.  Just as groovy was never designed to execute instructions in the least possible time.  If you want that, write code in C or assembler, just as a web app looking for maximum performance will be better off with custom-written code.


Reply | Threaded
Open this post in threaded view
|

Re: Grails vs Java + Spring

Konstantyn Smirnov
In reply to this post by antony
Could sign every single word in your post Antony.

Every technology can be used or misused. If you develop with care, you can make "profit" on pretty much any language or framework.  The Grails offers all sorts of facilities to make development/deployment process easier and faster.

Need to mention here of course, that grails as a framework is perfectly suitable for a "plain" web-app. Using it for RESTful app probably would be an overkill in terms of performance, but it was so damn easy to develop :) .
If I had to write a similar application right now, I'd still use grails in its core, but would add an vert.x endpoint to serve the client requests.
12