*

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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to