On Sun, May 22, 2011 at 11:48 AM, Jeff Schnitzer <[email protected]> wrote: > > optimal concurrency >
Thinking out loud here... this is an interesting phrase. Imagine for a second that GAE was built on Node.js or an equivalent fully-asynchronous server. In this environment, RAM is not the limiting factor, CPU is. Any single instance will scale up to almost any number of concurrent requests, limited only by maxing out a single CPU core. You only need another instance when you need another CPU core. This ignores the cost of RAM consumed by idle instances, but that is a sunk cost. Both old and new pricing strategies assume a single free instance to everyone no matter what. Yeah there is a cost for that but it's a cost that Google has chosen to accept, so it leaves the equation. Multithreaded Java servers may be somewhat less optimal than a purely async system WRT concurrency, but they should be good enough. My experience with JBoss clusters on modern linux is that unless you're doing long polling, you run out of CPU long before you run out of the ability to spawn new threads. So, if GAE had efficient levels of concurrency, the old pricing model (CPU time) would actually make a lot of sense - almost all apps would have a single instance until they're sucking down so much CPU time that they need another instance. RAM is not the scarcest resource - you'll run out of CPU cores long before you'll run out of additional 128M chunks of RAM. Of course, scheduling a highly concurrent instance is harder - a hot async instance will have a much larger impact than a hot single-threaded instance, and a hot multi-threaded instance will be significantly harder to manage than even a hot async instance. But this is why Google hires the smarties. It's the legacy single-threaded servers that makes CPU-time pricing unsustainable. These systems consume vastly more RAM than they should for equivalent amounts of traffic. They need to be priced much higher - but this price is likely going to be higher than any mass consumer application developer is willing to pay. Since-threaded blocking servers are just not cost-effective in 2010. They probably never were, but Google hid that from us. I wonder if this pricing model switch, which makes sense for the legacy single-threaded systems, is actually going to be a liability when everyone is converted over to multithreaded systems. At that point, CPU may be the bottleneck again. And the pricing model will need to change again. Put it this way: A single multithreaded Java appserver instance should be able to happily consume every last CPU cycle on a frontend box - and that's just the free tier. Or maybe Google doesn't believe they will ever be able to get close to "optimal concurrency", even with multithreaded systems. That would surprise me. Maybe the answer is that there needs to be two pricing models, or some pricing scheme that discourages development of inefficient single-threaded blocking applications. Jeff -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" 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-java?hl=en.
