On Wed, Jun 13, 2012 at 3:49 PM, alex <[email protected]> wrote: > > If by Non-GAE systems you mean mostly IaaS and stuff like Beanstalk then of > course they are "less sensitive", but again we're talking about different > service levels (hence different approaches in solving a specific > problem/challenge). Others (e.g. Heroku) simply make you set a fixed # of > instances. Well, that's one of the reasons I prefer GAE.
The fact that normal appservers can have hundreds of threads blocking on reads and GAE apparently can't doesn't really seem related to the "service levels". I prefer GAE too, but this means I want to congratulate the team for the many good things they do and hold their feet to the fire when they do bad things. "Degraded service == more profitable" is a perverse incentive, and will eventually produce undesirable development priorities and turn happy customers into angry customers. From a game design perspective, this is a bad way to structure a business relationship. There were problems with the original pricing model, and now we have problems with the new one. Let's talk about it. >> It's possible that Google can solve this problem entirely by getting >> better concurrency out of instances. Is there still a hard limit of >> 10 threads? > > Yes. BWT, 99% of such "problems" I've seen could be effectively solved with > push or pull queues. This doesn't really address the problem. Queues are serviced by instances. Datastore latency will still cause extra instance spinups. 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.
