When you talked about Grails' startup time I assumed you meant on a fresh servlet container. That's the first time I've seen build time called startup time. :) On Mar 20, 2012 10:41 AM, "mgkimsal" <[email protected]> wrote:
> Do all what stuff at build time? > > The dynamic stuff I referred to? I'm talking about building during > development. I deploy... once every few weeks. I'm *building* > multiple times per hour during development, and that's what I was > talking about. > > That said, *most* of the dev I'm doing is on classes/files that are > hot-reloaded, so I don't often endure the 90 second rebuild - in about > 80% of the cases I'm changing files that get hot reloaded and I'm > refreshing a web page in 2 seconds - nearly as fast as PHP! ;) > > On Mar 20, 8:09 am, Ricky Clarkson <[email protected]> wrote: > > I know next to nothing about Grails but is there no option to do all that > > stuff at build time, and if not, why not? > > On Mar 20, 2012 8:35 AM, "mgkimsal" <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > On Mar 16, 5:25 am, Rakesh <[email protected]> wrote: > > > > > > Grails' sweet spot is creating a web application (rather than web > > > > services) to do CRUD. > > > > > > Our platform is not about typical CRUD. We do not have a html > > > > front-end for example. Or a relational db. We use Mongodb. > > > > > As someone else pointed out, there are plugins for grails for mongo - > > > I believe the mongodb plugin is a bridge between GORM and mongo. > > > > > > We are also concerned about the runtime performance of Grails as well > > > > as how long it takes to startup in Jetty. > > > > > Grails' startup time is longer than Java, and that depends somewhat on > > > the size of your app. I'm dealing with a project with 150+ domains, > > > and a similar number of controllers. There's a good 40+ seconds spent > > > loading and decorating the classes with dynamic stuff and, from what I > > > can tell, doing something with the classes with Spring. I'm no Spring > > > expert, but I was trying to do some tracing to determine why the app > > > takes 1.5 minutes to start up, and much of the time was spent simply > > > finding all the classes on disk, loading them up, and doing something > > > with Spring to the classes (honestly don't remember exactly what it > > > was). > > > > > To that end, 'pure' Spring outside of Grails might be faster startup, > > > but I'm not sure *how* much faster. What are you startup times now, > > > and why do they concern you so much? > > > > > Are you using Grails 2 or Grails 1? > > > > > Tomcat will probably be at least a bit faster, if only because it's > > > the defacto standard in the Grails community, and I suspect the Tomcat/ > > > Grails combo has had a bit more love/attention than Jetty has in the > > > past few years. > > > > > You mention the startup time, then mention performance. Have you run > > > any performance tests on your current Grails setup as a benchmark? > > > > > Benchmarks out there all show Groovy being slower than 'plain old > > > java', which is to be expected, but in 'real world' tests, I've not > > > found Grails to be a performance bottleneck in and of itself, and the > > > usual suspects of disks and databases have tended to be the bigger > > > issues. Once those are addressed (better indexing, optimize queries, > > > etc), then yes, just the app stack is left, but have you measured how > > > much of a bottleneck Grails itself is in your situation? What is it > > > providing, and what are your performance goals? > > > > > > So can anyone suggest an alternative? Performance and load are > > > > important. Being able to expose web services easily from Java is also > > > > important. > > > > > > I was thinking using Tomcat + Spring, mainly because its a stack I > > > > know and Tomcat can handle a huge load and I can pick and choose the > > > > bits of Spring I need. I would consider something lighter weight but > I > > > > really don't want to muck around with web.xml files and the usual > > > > standard java web app crap (which Grails does a fantastic job of > > > > abstracting away). > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "The Java Posse" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]. > > > For more options, visit this group at > > >http://groups.google.com/group/javaposse?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
