Hello, Thank you Sarath for this very nice wrap up and for the figures. I totally agree with your findings.
To abandon all use of frameworks even the ones provided by GAE (e.g. JDO) would mean to give up a lot of benefits and to end up with messy code especially for large application. Also frameworks might provide features that are not available through any low level API. In my application I need e.g. full-text search which is not supported by GAE(!). So I use the compass framework and lucene which seems to be the only option at the moment. To load the search engine is even adding to my spin-up time and I do not see a good way to solve this problem. Frameworks and libraries are not only just about software engineering or design pattern. They most of all provide us with additional functionality and free us from the task of rewriting what was done before. So eventually you end up with a bunch of jar in your project. And loading them seems to be what kills the spin-up time. Warmed instances seems to be the best fix for the moment. But from a CO2 perspective we should avoid such wasteful solutions. On the longer term there should be something else. Maybe to do a memory snapshot of the JVM when it is suspended and to kind of keep that in local storage or cache. The class loader is another idea. Even though it might become a nightmare with all the different versions. And finally I think the functionality of GAE should be extended and optimized. I do not understand why suddenly JDO or JPA is at disposition, even if it is part of the core SDK. In my case I would appreciate if GAE would include full-text search. And I am sure there is other functionality that could become part of the platform. Tobias On Mar 30, 11:29 pm, Sarath <[email protected]> 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 delayedstartup. > > Some have suggested to remove spring/di/jpa/jdo. While this is true, > it solves much of theproblem- 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 javaapp. > > 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 oneshouldNOT be > considered for optimization. > > For #1 a recommendation is warmstartup. 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 takeshouldbe during > the class loading. Grails/Spring have a bunch of libraries that are > almost 1 mb sometimes. > > An assumable solution would be to preload / share these libraries in > the parent classloader and have some kind of manifest either inapp- > 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)" <[email protected]> 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 > > <[email protected]>wrote: > > > > In the mean time, here are some ideas for reducingstartuptimesby > > > 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 <[email protected]> wrote: > > > > Great information, Ikai. > > > > > I really feel that "instances"shouldbe 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 > > > "GoogleAppEngine for Java" group. > > > To post to this group, send email to > > > [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<google-appengine-java%[email protected]> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-appengine-java?hl=en. > > > -- > > Ikai Lan > > Developer Programs Engineer, > > GoogleAppEnginehttp://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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
