On Wed, Sep 7, 2011 at 9:02 AM, Tim <[email protected]> wrote: > > > On Wednesday, 7 September 2011 15:46:21 UTC+1, Jon McAlister wrote: >> >> Understood. And again, apologies. We mean well, we messed up, we're >> working on it. >> >> > An authoritative explanation of the intent (there's that word again >> > Greg) of >> > the scheduler / billing logic would be more than welcome and may reduce >> > the >> > gap between why you guys think the pricing is reasonable and many of us >> > in >> > here think it's not. >> >> Agreed. The system is large and complex, its hard to understand and >> hard to explain. Ultimately I am confident that everyone can find a >> reasonable outcome but trying to work through these things at scale >> (i.e. helping hundreds of thousands of developers to change something >> simultaneously) is quite difficult, practically impossible. We're >> working on it. > > OK, so that's made me much happier, thanks Jon.
I'm really glad to hear that! > I know how hard it can be to explain such things without leaving room for > misconceptions to form (had similar experiences designing a system and > scheduler for a lazy ticking memoising computational grid for tens of > thousands of machines), but maybe some worked examples of how you intend the > billing to work for certain scenarios might help ? > eg "app has busy bursts and then nothing", "app has busy bursts and then > ticks along normally until next burst", "app has 'swells' (gradual ramp up > and ramp down of traffic over an hour or two)", "asymmetric bursts (like a > bell curve with skews)" I think that is an excellent idea. > I'm willing to accept that the scheduler is always going to making guesses, > but things like the fact that you're basing billing of "Instance hours" on a > notional level of service which should be less than the "actual" instance > hours suggests to me that the intent is to let you tweak the parameters of > the opportunistic apsects of the scheduler without changing the user > experience of billing for every such tweak (say deciding to keep the true > idle instances active for different periods in excess of 15 minutes > depending on time of day to avoid repeated reloads, but such changes won't > affect the bills), which sounds more in line with your PaaS aspirations. Exactly. The other thing that happens is that this imprecision allows us to paper-over internal infrastructure details. As an example, when we automatically move an app across datacenters (because of weather, power, maintenance), the right thing to do is actually run instances in both the source and destination datacenters at the same time during the transition. But we don't want to charge developers for this doubling, that would be wrong. By having the billing formula respect max-idle-instances as a hard ceiling, we do the right thing here and eat these costs ourselves. > So, based on that understanding of what you're doing, I'm going to take the > time I was spending looking at options elsewhere and put it into moving my > data onto HR so I can then switch to python 2.7 with concurrent requests, > and then see how the out-of-preview works in practice for my app. Glad to hear! > Cheers > -- > Tim > > -- > 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/-/guF1P8yyofkJ. > 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.
