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 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'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. 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. 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.
