On Thu, Jun 14, 2012 at 5:01 PM, Jeff Schnitzer <[email protected]> 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.
The primary incentive is the long-term incentive, I don't see how that would be different between today and in N years. I don't see when it would ever be sensible to do what you are describing. > >> } 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. It does not presently consider this. It seems like a reasonable approach. > > 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. > -- 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.
