On Fri, Jul 22, 2011 at 7:09 PM, Luca <[email protected]> wrote: > Johan, > it seems to me the problem is rule 4/ below. > Shouldn't the rule be: > Idle Always On instance > Idle Dynamic instance > instead? > In this way, if you have a dynamic instance on, it will not handle traffic > unless the always-on ones are busy. So when the traffic decreases, and the > dynamic instances are no longer needed, they will be correctly shut off.
I confirm the current rules is Idle Dynamic instance > Always On instance While I agree your proposition make sense in some cases, it sounds also good to take advantage of the Dynamic instances that have just be spawned especially if the startup cost is high. Like Gregd highlighted in his pricing faq, Always On will became a settings to control the number of idle instances you would like to have running. Q: How will Always On work under the new model? A: When App Engine leaves preview all Paid Apps and Apps in Premier Accounts will be able to set the number of idle instances they would like to have running. Always On was designed to allow an app to always have idle instances running to save on instance start-up latency. For many Apps a single idle instance should be enough (especially when using concurrent requests). This means that for many customers, setting an App to be paid will mean a $9/month minimum spend, you can then use the 24 free IH/day to keep an instance running all the time by setting Min Idle Instances to be 1. > I also think an auxiliary problem is with rule 2/ > If you spawn a new instance just because the others are all busy, you may > tend to have too many instances. > The fact of spawning new instances should be configurable, depending on how > many requests are already queued for the instances you have already active > -- 0, 1, more, etc. > More in general, if you allowed users to specify how much it costs to them > to delay serving a request, it would not be difficult to synthesize for each > app an optimal decision policy to decide whether to switch another instance > on or off. This can be done using tools from dynamic optimization / control > theory. I would be glad to help if the people there need guidance on this > (I used to be in the research group there till a month ago). It sounds to me that the scheduler knobs are there precisely to address this: http://code.google.com/appengine/docs/adminconsole/performancesettings.html Let me know if I overlooked it. > Luca > On Thursday, July 21, 2011 5:56:42 PM UTC-7, Johan Euphrosine (Google) > wrote: >> >> After speaking with Engs, I think I can explain what is going on: >> >> Here are the current scheduling rules: (> reads as has priority for >> handling the incoming request) >> >> 1/ Idle Always On instance > Spawning a new Dynamic instance >> 2/ Spawning a new Dynamic instance > Busy Always On instance >> 3/ Idle Dynamic instance > Busy Always On instance >> 4/ Idle Dynamic instance > Idle Always On instance > > -- > 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/-/X8gH6jjIK0MJ. > 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. > -- Johan Euphrosine (proppy) Developer Programs Engineer Google Developer Relations -- 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.
