I don't personally see it as "degraded == more profitable", quite the opposite.
And to remind you while you're bashing, AWS (since you mentioned it) has its moments too http://blog.phpfog.com/2012/06/15/post-mortem-on-aws-outage/ In this particular one, degraded EBS, would degrade a handful apps even with a 1000 threads. As you might notice, noone sees it as a "degraded == more profitable". In fact, at this point one can probably choose between having users being extremely angry (because an app would probably just seem down) and go away, or sustain an temporal costs increase but at least keep users "less-angry". On Friday, June 15, 2012 2:01:26 AM UTC+2, Jeff Schnitzer wrote: > > On Thu, Jun 14, 2012 at 9:54 AM, Jon McAlister <[email protected]> wrote: > > Jeff Schnitzer: > > } "Degraded service == more profitable" is a perverse > > } incentive, and will eventually produce undesirable development > > } priorities and turn happy customers into angry customers. > > > > This captures the issue well. It may seem at first like we've got > > an incentive, but in truth the second-order effects are a much > > stronger incentive for us. We care very much about predictable > > reliable performance and continually work to improve here. > > Thank you for the thoughtful response. FWIW, I have full faith that > the GAE team today is doing their best to create a more reliable, more > efficient solution. However, while I am hopeful, it's hard to predict > what Google of 10 or 20 years from now will be like. In 10 years I > expect to still be in business, but with ten times more code that is > all woven into GAE's services. But maybe in 10 years Search will have > crashed, replaced by The Next Thing (!?), and the bean counters are > going to take complete control. > > In the long run, behavior follows incentives. We-the-customers, who > are investing heavily on a highly locked-in platform, would feel a lot > better knowing that both primary and secondary incentives are aligned > in our mutual interest. > > > } Is there still a hard limit of 10 threads? > > > > Yes, but probably not for the reason you expect. The primary > > issue we run into is memory management. If we raised the default > > to 100, many apps would then see out-of-memory deaths (more than > > they do now), and these deaths show up differently for > > python/java/go. The right path forward is more intelligent > > algorithms wrt memory, providing configurability, and so on. This > > is an example of the kinds of projects we work on for the > > scheduler, but as with any team we have to prioritize our > > projects. I'd recommend filing this (or any other desired > > scheduler enhancements) on the public issue tracker so they can > > get feedback/data/votes. > > Does this limit still apply to larger instances? If an F2 has twice > the memory and CPU of an F1, it should be able to handle the same load > as two F1s. In theory, any app which requires dozens of instances > would be better off switching to F4 frontends. But not if there's > still a 10 thread limit. > > Jeff > -- 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/-/yo2_2OciK00J. 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.
