Amazing, Andrei. If you can get those startup times going with GWT and the complexities you mentioned in your app, then clearly stripping out DI and using low-level API (and likely jar'ing everything) is a mega contributor to reducing startup time. I would hate to have to spend the team's time stripping that stuff out, i would just pay for higher idle instances until request #7865 gets implemented.
I agreed that only dispatching to warm instances makes the most sense and would negate the need to have high idle instances or stripping out frameworks like Guice and Objectify...but if at some point in the future as the code base grows even larger and we are consistently exceeding the hard limits then we have to either breakup the app as Brendan mentions or start stripping out frameworks as several of you have mentioned. Clear GAE was having a bad day when i posted this in the first place because we haven't had these issues of exceeding the hard limits on warmup times and we've only been adding to the code base since. Maybe it was just that day, but the other question that I asked in my original post was why were our Staging cold-startup times faster than our Production warm-up requests? I could understand a few more seconds for warmups, but the warmups in production on F4s were exceeding the hard limits and the cold starts on our staging environment on F1s were happening in like 30 seconds. Some other part of the infrastructure must be used during warmups and that "part" must have been having a really bad day. Why else would warmup requeests on F4s be able to lose to cold starts on F2s? Rock on, -Hardwick On Wednesday, July 25, 2012 6:28:01 AM UTC-4, Andrei Volgin wrote: > > I have a large GWT app with over 50 complex data entities with very > complicated relationships between them. There are over 100 RPC methods, and > I use various GAE services (Users, Memcache, Blobstore, Images, and Mail). > My new instance startup time ranges from 4 to 5 sec on F1. Sometimes it > goes a little higher. The lowest was 3.6 sec. I use the low-level API and > no DI. Productivity tools are nice, but they have their cost. > > In any case, if Jeff's suggestion is implemented (dispatch only to warm > instances), it would not matter if the start up time is 4 sec or 40. I > followed this discussion closely, and to me it is obvious that the existing > GAE mechanism is inferior to what Jeff is proposing (for any number of > instances). There may be a good technical reason why the GAE team chose > their current implementation. It is also possible that GAE was built by > engineers who did not think in terms of web user experience, and who > believed that a rare 30 seconds delay is the acceptable price to pay for > some other benefits of the current implementation. This proposal was > already starred by many people (issue 7865). It would be nice if the GAE > teams takes another look and tells us whether we should expect any changes. > I am sure a lot of app developers would like to know whether they should > optimize for fast cold starts. These optimizations are expensive (both in > direct development time and in lost productivity), so this is not an idle > question. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/ncTsPLWS7JUJ. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
