Hello Matt, First of all, I appreciated your Google I/O talk. It's always interesting to see what Google's thinking about my favorite language :-).
Secondly, I feel that we're caught in a Dilbert comic strip, in particular, this one here: http://imgur.com/0AHeS4Q . I.E. on one hand the official company line is "J/GAE is great! So is DI/AOP!" and then on the other hand the unspoken "gentleman's understanding" is that if developers use DI/AOP, we get unacceptably long startup times. Startup times that turn off and rebuff users. Other people have said this before, but I will reiterate: startup times that far exceed 2-3 seconds are not acceptable in the long-term. It doesn't matter if you reduce startup times of an app from 30 seconds to 10 seconds because the user has already browsed away after the first 5 seconds. In complete fairness to Google, I'm not sure this problem is fixable without a whole lot of work and money spent. I want to say the answer is just taking a snapshot of the JVM + app (as someone already mentioned in this thread) and then redeploying the snapshot, but it's probably much more complicated than that. Java is a heavyweight in terms of initial startup - we're always going to have higher startup times compared to Go, PHP, etc. *Feature Request:* Can you guys put up an automatic "Loading.../Redirecting..." page when requests are routed to cold instance starts? The major problem here really isn't the loading time, it's that there's no user-facing acknowledgement that something is going on. When a user clicks a link and gets directed to a cold-start instance they only see a blank page - they don't know if the page is loading, if their browser crashed, if the site broke down, etc. Have GAE offer an option where if an instance is cold started, and the loading is taking more than x seconds, the user is shown a "LOADING..." graphic, then is redirected to the page they requested when the instance is finished loading. This isn't new technology for Google - Gmail does the same thing if email loading is slow. Again, I enjoyed your talk, and thanks for the opportunity to discuss. If you're ever in Chicago hit me up and I'll buy you a beer ;-) -Vinny ----------------- -Vinny P Technology & Media Advisor Chicago, IL My Go side project: http://invalidmail.com/ On Monday, May 20, 2013 7:19:27 PM UTC-5, 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 [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.
