> > > >> In a very rare case, App Engine sometimes needs to direct a request to >> another instance(even if there is an idle instance) for some reasons. I >> think this is a nature of a distributed and shared system like App Engine. >> >> > It would seem that scheduling a request to one of 2 resident plus a couple > of idle instances would be more efficient even in a distributed/shared > environment that incurring a 29sec cost of starting up a brand new instance > though. >
I think the implication is there, are multiple "instances" of the scheduler. It might because the app is being served out of multiple datacenters, or even just multiple instances within the same datacenter (one per rack?). These scheduler instances dont know what app instances are already being run by *other* schedulers. They are self contained. So if a request happens to hit an scheduler instance, that has no app instances running, there is nothing to do but wait for a appstartup. Even though there are maybe other app instances sitting idle. Google probably does some complicated routing to try to always route a incoming request to a scheduler that is likly to have a instance for your app. Maybe some sort of consistent hashing. But sometimes, that jsut will not work out. maybe the scheduler lost connectivity with the router. Because the router will also be a distributed service - probably running right at the edge of Google network. Maybe the instance scheduler is being decommissioned - taken out of service. For a while it will still have a app instances running, but they will be inaccessible. At scale - particully distributed - nothing happens 'instantly' and consistently, eventual consistency rules. In general AppEngine is engineered for scale, tremendous scale. An app with many app instances running (so each scheduler should always have running app instances) - will not notice these occasional blips. Whereas with a mostly idle application, the relative chance of getting a routing 'misdirection' is much increased. Now of course Google could work more to lower the chance of it happening. eg having the routing frontends and the schedulers being more tightly coupled, but the overhead of this, is likly not worth it. It would vastly complicate the overall system, both in code, and bandwidth, that it would probably slow down all requests somewhat. (Note, I dont know this is how Google implements appengine, but it seems likely) > > > My instances start typically in around 4secs but I am seeing a lot of > longer startup times. I need to work out how I can achieve the same goal > with the current 2.7 runtime, so as to avoid these sorts of hits in > performance. > Get more traffic! The more traffic, the less these things will happen. -- You received this message because you are subscribed to the Google Groups "Google App Engine" 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?hl=en.
