Hi Matt, Thanks for joining this discussion (I think my tweet did wonders :-) Anyway back on topic I agree with other people that requests should never go to cold instance startups.
I also wonder if shaving of 2 secs will have that much impact, does it really matter going from 20s to e.g. 18s? Or from 10s to 8s? For me the discussion goes further then only DI and/or AOP. Personally I favor Spring, but not only for DI, also it's strong (web) binding capabilities (and in particular i18n data binding). It's just a complete stack in which I can do do traditional MVC, and add REST as wel very easily. It makes developing webapps productive compared to e.g. using plain servlets. Of course I tried alternatives like Jersey framework but even those very not satisfactory in terms of cold startup times. A plain Jersey app with 1 simple REST resource (without classpath scanning or even using JPA) takes 17s to startup. And last weekend I experienced with a simple Google endpoints app based on http://www.planetjones.co.uk/blog/19-05-2013/google-app-engine-endpoints-with-java-maven-part1.html but cold startup time for this is also 12s. Could you elaborate on your "The vast majority of Java apps on App Engine boot very fast" statement. What is fast? 3s, 5s, ..? And on what technology/frameworks are these vast majority of apps based? It could help us getting a broader picture. Autoscaling is one of the unique features I like about GAE (inclusing strong api including memcache, search, etc.). So setting minimum idle instances goes against this principle. But this might be interesting for some apps. At the moment I'm using GAE successfully for some clients, but those are small internal 1 instance apps. And I can say I'm happy with it. But I probably would not use it at the moment for a public large enterprise webapp with unpredictable page visits. Regards, Marcel On Tuesday, May 21, 2013 2:19:27 AM UTC+2, Matt Stephenson wrote: > > * > > First of all, thanks for attending the Google I/O talk, we got great > feedback, both positive and constructive. It was a great I/O and very nice > to hang out with many of the developers at the event. > > This talk is based on my previous experience where I have worked with and > promoted the use of Spring, Guice, AspectJ, and many other great java > technologies. I in fact mentioned my favorite configuration for restful > services during my talk, which includes Guice. > > Many things were taken out of context in this thread from the talk I gave. > In particular the fact that you shouldn't use DI. I think DI works > great, and I was merely giving people tips on getting fast startup for a > java app. I do still have my Rod Johnson bobblehead from when I attended > The Spring Experience in 2007 on my desk. It's a strong reminder of where > we started with Spring 1.0 and where we're at with new DI like Dagger. > > On the orthogonal issue of cold start requests, we're certainly doing > things to make sure that requests go to warm instances whenever possible. > Whatever we do to improve this behaviour will be much simpler if your > application starts up quickly. > > Shaving 2 seconds of boot time off your application has a significant > positive impact on billing and reliability when booting a large amount of > instances needed to scale your application. There are actions that you can > take on the application level to improve this, and internally we are also > working hard on improving scheduling and boot time. > > If your application is seeing tons of cold starts, let us know, and we are > happy to look in depth as to what is going on in our infrastructure. The > vast majority of Java apps on App Engine boot very fast, and we are willing > to spend time now to improve the few apps experiencing high variation of > time during startup. > > Recently we added dynamic loading requests to the administrative dashboard > graphs. Hopefully this can help with identification of when changes to the > application impact performance. > > Would it be easier if we offered the minimum idle instances tuning > parameter via an API? That way you could actually do your own prediction > and adjust the min idle instances programmatically. That actually sounds > very reasonable to do, but I'm just throwing ideas out now. We’re very > open to any ideas that would make this simpler. > > In my Google I/O talk my goal was to show that if you do use certain > facilities in common java frameworks, you need to optimize a few specific > points around them. > > Matt (always reachable via irc : mattstep on irc.freenode.net in > #appengine) > > > * > On Monday, May 20, 2013 11:29:46 AM UTC-7, Marcel Manz wrote: >> >> Gooogle really never should have used the term 'resident' instances. >> >> It leads to a lots of confusion, making many developers believe that >> these would be the primary instances requests get routed to. But that's not >> how GAE works. These are instances that should have been named something >> like 'scale-buffer' instances or similar and only take requests while GAE >> spins up more dynamic instances. >> >> This has been endlessly discussed and the only way forward is for GAE to >> announce in one of their next updates that requests no longer get routed to >> cold instances. Period, end of discussion and we'll all share our love for >> GAE much more ;-) >> >> Nobody here really understands what is taking them so long so make this >> simple scheduler change, where the scheduler looks up a flag - instance up >> - good, route there. Instance not up - don't route there. Instances getting >> busy - start up more instances and let the scheduler wait addressing them >> until they are up and running, accepting additional queue time in case all >> instances are fully busy serving requests (which is way much better than to >> wait for a full cold start). >> >> >> >> -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
