Here is some more insight. http://bit.ly/d2lOnv
Looks like I was way off on numbers for Grails. Like I said, We should think less about work arounds, and frameworks-on-diet (not that they dont work) and rather look at an out of box solution. -Sarath. On Mar 31, 2:29 am, Sarath <sarath...@yahoo.com> wrote: > This is getting really interesting. I have been follwoing this post > from a couple of days. > > I managed to see What exactly is ammounting to delayed startup. > > Some have suggested to remove spring/di/jpa/jdo. While this is true, > it solves much of the problem - These are the reason why I would > choose java over python. > > I may be wrong here - But I tried this experiment. > > I had four versions of a simple java app. > > one with grails > one with spring (full di - context: scan etc) > one with spring (lazyloading, ) > one with slim1.0 > one with NOTHING (only commons logging) > > I realised there are two parts to the load time. > > The load time from google. > The load time from the libraries. > > I believe from a developers perspective the second one should NOT be > considered for optimization. > > For #1 a recommendation is warm startup. While in theory it might > sound good, the elasticity and managment will take it back to EC2 type > like baz suggests. > > For my experiment the results are like this > > Version - > Google Warmup - Framework Warmup > with grails > - ~9+ secs - ~4secs > with spring (full di - context: scan etc) - > ~4+ secs - ~3 secs > with spring (lazyloading, ) - > ~4 secs - ~2 secs > with slim1.0 - > ~2-3 secs - <1 secs > with NOTHING (only commons logging) - ~2 secs - > <1 sec > > Now I dont know what exactly Google spins down - I assume just the > apps - not the whole container. In which case, There is a lot of load > while loading the libraries. I can only guess, (corrections expected > from technical team at google) most of the time take should be during > the class loading. Grails/Spring have a bunch of libraries that are > almost 1 mb some times. > > An assumable solution would be to preload / share these libraries in > the parent classloader and have some kind of manifest either in app- > web.xml or manifest.mf to use them. It may not be a fully loaded > osgi type of a stack but a noval hierachied classloading with ways to > selectively load libraries. Otherwise there be some other classloading > mechanism that is fast. like probably from memcache. > > Google tech team - to comment/ > > I will try to upload some actual numbers from my logs and post the > information. > > -Sarath > > On Mar 31, 1:54 am, "Ikai L (Google)" <ika...@google.com> wrote: > > > David, that post mirrors many of the points made here: > > >http://www.answercow.com/2010/03/google-app-engine-cold-start-guide-f... > > > There's one or two more tips on that page. > > > On Tue, Mar 30, 2010 at 12:47 PM, David Chandler > > <turboman...@gmail.com>wrote: > > > > In the mean time, here are some ideas for reducing startup times by > > > shrinking our apps. I went from 8.1s to 2.5s mainly by eliminating > > > Guice, and I would expect similar results with Spring. I can > > > definitely live with 2.5s... > > > >http://turbomanage.wordpress.com/2010/03/26/appengine-cold-starts-con... > > > > /dmc > > > > On Mar 30, 3:04 pm, Baz <b...@thinkloop.com> wrote: > > > > Great information, Ikai. > > > > > I really feel that "instances" should be completely avoided in concept > > > and > > > > language on the GAE. What if the feature was simply an enable/disable > > > deal > > > > called "Warm Scale". If it were enabled, then your *next* instance would > > > > always be warm, regardless of how many instances you already had. This > > > would > > > > be most noticeable and suitable for low QPS production apps that are > > > > constantly going from 0 to 1 instances (as you mentioned), but it could > > > > still be important for others, say, for a super-high-profile site, or a > > > > situation where your QPS is right at the threshold of instances and > > > > oscillating back and forth between two instances. Whatever the > > > > situation, > > > if > > > > the solution were generalized like that, and most importantly not tied > > > > to > > > a > > > > SPECIFIC NUMBER of instances, it would be up to the user to decide how > > > > important it was for them and whether to enable it. > > > > > Cheers, > > > > Baz > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Google App Engine for Java" group. > > > To post to this group, send email to > > > google-appengine-j...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-appengine-java?hl=en. > > > -- > > Ikai Lan > > Developer Programs Engineer, Google App > > Enginehttp://googleappengine.blogspot.com|http://twitter.com/app_engine -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
