Well yes, they have shifted the 'burden' but I see it in a different way.
The 'old' way, pretty much promoted low cpu use, even if that came at the expense of latency. The slow requests, would necessitate lots of instances - costing Google.
The 'new' way promotes keeping your latency down. Quick requests gives higher queries per second (per instance). Meaning less instances.
By charging for actual instance usage, they are promoting keeping the number of instances down.
So the developer should aim to keep the number of instances down - saving money.
People who need, want, (or can't be bothered to optimise to avoid), slow requests will pay - closer to what it actully costs Google.
Google dont want you spinning up instances, and tearing them down quickly. Its that spinning up, that 'costs'. Rather then charge you 15 minutes 'overtime' they, could just change $0.02 per instance started (as a fee). Same result.
(And in the shorter term, there is also compensation offered for lack of multi threading/processing in python)
On 19 May 2011 15:37, Stephen <sdeasey...@gmail.com> wrote: > On Thu, May 19, 2011 at 2:52 PM, Barry Hunter <barryb...@gmail.com> wrote: >> >> With 15 minutes Google appear to be offering a compromise. > > This is the problem: they haven't fixed anything they've merely > shifted the burden by compromising. > > Under the current scheme, as Greg explained, full-fat Java Enterprise > apps which take 25 seconds just to initialize and therefore can't be > killed and restarted quickly take up memory which Google hadn't > accounted for. Under the new scheme where time is charged in blocks of > 15 minutes the burden has been shifted from Google to writers of > efficient Python and Go apps -- Enterprise Java apps are still free > riding. > > It can't possibly be in Google's best interest to have > the-next-big-thing scrappy startup subsidising Big Co's legacy TPS > reports. > > How about this: > > Expose a scheduler tuning knob, default off, which when enabled > reduces the kill-timeout from 15 mins to 20 seconds, and the > deadline-exceeded timeout to 20 seconds. This would be completely > unworkable for the average full-fat Java app so Enterprise customers > will not enable it, but an efficient Python app which starts in 100ms > or a compiled, statically linked Go app which starts in 20ms can be > started and stopped efficiently by the original scheduler algorithm > and be charged in units of 20 seconds. The new backends feature is now > available for anyone how needs more resources. > > -- > You received this message because you are subscribed to the Google Groups "Google App Engine" group. > To post to this group, send email to google-a...@googlegroups.com. > To unsubscribe from this group, send email to google-appengi...@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. > >