On 19 May 2011 17:31, Stephen <[email protected]> wrote: > On Thu, May 19, 2011 at 4:17 PM, Barry Hunter <[email protected]> wrote: >> 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. > > > No, the way it currently works is if your apps latency > 1000ms > (figures of 800-900ms have also been mentioned) it won't scale. The > lower the latency the more they scale it. So the incentive has always > been to write low latency apps.
For practical purposes yes - to be able to scale. But not from cost. If you where using your cpu over 10 instances, costs roughly the same as using that cpu on two instances. > > The new scheme promotes low cpu usage just as much as the current > scheme, as shown in Greg's formulae. > > There's no real change here. > > >> By charging for actual instance usage, they are promoting keeping the >> number of instances down. > > > Here's the change: they're not charging for instance usage, they're > charging for usage +15 mins. You can argue that the +15mins is a cost > recovery mechanism for resources used during instance startup, but > there is a large difference between a Java app which takes 25 seconds > to initialize itself and a a compiled, statically linked Go app which > is ready in a few 10s of ms. Startup time is irrelevant. Its its ongoing usage that is important. > > So inefficient Java apps are being undercharged, so Google is adding > +15mins to the billing, even if you're not an inefficient Java app, so > now efficient apps are being overcharged. An efficient app, doesnt even need a new instance. inefficient apps (ie high latency) will need more instances to serve the same traffic. So they pay for those resources. > > >> Google dont want you spinning up instances, and tearing them down >> quickly. Its that spinning up, that 'costs'. > > > Starting up and shutting down is the 'auto' in auto-scaling, which is > a premier feature of Google App Engine. It's still there, just far less granular. Do more with less instances. > It may 'cost' to startup, but > it doesn't cost the same for an efficient Go app as an inefficient > Java app, yet they're charged the same 15mins, and therefore modern > efficiency is subsidising legacy bloat. Its not the cost of the "application" starting in the instance itself (which will depend on the application, and even the runtime to an extent). The time (1-25 seconds) starting the app, is irrelevant in the terms of a instance lifetime. But the very cost of starting the instance itself (before any code is run) - as mentioned getting the code to the instance (potentially 3000 files), even things like identifing a suitable node to run it on. Maybe the scheduler has to bring online more nodes. Not details you have to worry about, granted. So its just hidden behind the 'instance fee' > > -- > 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.
