On Wed, Jul 18, 2012 at 3:55 PM, hyperflame <[email protected]> wrote: > > "Massively" being the key word there. Every Google service is massive. > Even abandoned or low use Google services (i.e. Wave, Buzz) are going > to use the equivalent of a minimum 10,000 F4 instances. The GAE > scheduler does inefficient scheduling at less than 50 instances. It > works wonderfully once you hit scale at 100+ machines(correct me if > I'm wrong, but most of the people seeing problems here are probably > less than 50 instances).
This is an interesting discussion. How many apps do you think are on GAE that run 100+ instances? 1000+? While these are certainly going to be the "important" apps for Google, I suspect they are fairly few in number. With a couple exceptions, the owners are very quiet on this list. I wonder also how many of them are on multithreaded runtimes, and of those, how many of them are on Java runtimes. >> b) By waiting for instances to warm up first, I don't think you would >> really increase the maximum depth of the pending queue by a whole lot. > > I would have to disagree with you on this. My experience with big > websites tells me that requests can very quickly pile up if you're not > handling them expeditiously. I think we're looking at this wrong. The question is not "should there be more than a single queue"; I certainly agree that we certainly don't want one loadbalancer falling over and taking down a thousand pending requests. The important question is "should requests go to a queue that is locked to a single (unstarted) instance", which is a different question. It's certainly possible to have multiple queues with the ability to route requests to active instances. At Google scale there must certainly already be multiple queues; obviously one computer cannot route the zillions of requests per second that www.google.com gets. Continuing the MegaWalmart example, you don't need to have one big line routed around the store; you can have a number of lines each of which route among banks of cashiers. Presumably GAE has some sort of equivalent construct. "Less than 1% of your customers were inconveniced. 99% of people still had a decent time checking out." is not very comforting. If 1% of Google searches took 8+ seconds to respond, the Googleplex alarms would deafen people as far away as Oakland. > Just to be clear, I am agreeing with you in that the GAE scheduler > needs work; it is currently optimizing for high-scale apps, and not > apps that are using double-digit or lower instances. I fear that GAE is optimized for single-threaded Python2.5 apps which take 2s to spin up, an environment that is becoming less relevant as time goes on. Given an app that takes 20+ seconds to start, would a high-traffic app work any better than a low-traffic app? Jeff -- 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.
