|the min instace time is 24 hours?||saintthor||9/4/11 11:25 PM|
if no request to the app for a whole day, the instace time will be 24
|Re: the min instace time is 24 hours?||James Gilliam||9/5/11 8:14 AM|
After software update no instances are running. Once an instance is
created it never goes below 1. Why can't the the minimum instance be
zero instead of 1? Forget it, GAE will just cut free instance hours.
|Re: [google-appengine] Re: the min instace time is 24 hours?||Greg D'Alesandre||9/5/11 12:21 PM|
I'm not sure I completely understand the question, but if you are serving no requests for a day you will have no instance usage at all. If you serve 1 request, you'll likely get 1 instance spun up to serve the request, then after you have served the request the instance will go away after 15 minutes. This is the behavior you should be seeing today.
I hope that helps explain it, if I misunderstood the question please let me know.
|Re: [google-appengine] Re: the min instace time is 24 hours?||Deepak Singh||9/5/11 12:54 PM|
I am a new comer to GAE despite being aware of new pricing model.
I have my application @ metasearchprodenv.appspot.com.
At the time of loading the application, a method, say loadingMethod, is called which internally makes 4 web service call one-by-one and takes around 40 sec in total and then goes to finish.
So what i observe is when there is no traffic for say 1 hour and i hit the url, it loads the application again from scratch and calls that loadingMethod and then loads the application on the client which gives user a long waiting time for application to load on client machine.
And it happens every time i hit the url if there was no instance ready before.
So i think creating a new instance is all about initialising all the classes of application from scratch. Right ?
If it is so, let me know how can i optimise the application so user does not have to wait long.
|Re: [google-appengine] Re: the min instace time is 24 hours?||Greg D'Alesandre||9/5/11 1:03 PM|
Hi Deepak, welcome to App Engine!
If you are using a free application there is no official way to do this (I'm sure some folks can chime in from the list on the unofficial ways to do this). If you opt in a paid app, you'll be able to choose the X number of idle instances. This basically means App Engine will always keep X instances running (even with no requests) so you won't have to suffer through startup times the first time you hit an app after a long time with a hit. This is currently handled by "Always-On" which basically does the same thing but you don't get to choose how many idle instances you want.
Hope that helps,
|Re: the min instace time is 24 hours?||Tammo Freese||9/5/11 3:24 PM|
Let's say I have an app that gets a traffic spike at the start of the
billing day, lasting for 5 minutes, and leading to 4 instances being
fired up. There is no other traffic the whole day. Max idle instances
is set to 1.
Is it possible to predict how many minutes of the quota that consume?
Of course I would love the answer to be simply 20 minutes (5x4
minutes), but I'm sure that's wrong. Here are 4 scenarios I could come
up with ranging from 80 minutes up to 1,560 minutes:
"Die Instance Die!"
The scheduler notices the drop to zero traffic and kills off all
instances immediately. For each instance 5 minutes + 15 minutes
startup fee (see FAQ) = 20 minutes. 80 minutes overall.
"15 Minutes Of Paid Idling"
The scheduler lets all instances run 15 minutes after the last request
and kills them off then. The 15 minutes count as idle time, however.
Because max idle instances is set to 1, we get 5 minutes + 15 minutes
startup fee + 15 minutes idle time for one instance, and for the other
three 5 minutes + 15 minutes startup fee. 95 minutes overall.
"60 Minutes Of Paid Idling"
Same as before, but the 15 minutes the instances are kept running do
not count as idle time (idle time only being time after the 15 minutes
without traffic). 35 minutes per instance, 140 minutes overall.
Same as before, but the scheduler keeps 1 instance running as long as
it wants to. Max Idle instances is 1 (and currently cannot be set to
0), so that would be perfectly "legal". One instance up to 1,440
minutes (one day) + 15 minute startup fee, the other three 35 minutes
per instance. Up to 1,560 minutes overall.
I included the last scenario to show how unpredictable the new billing
feels to me.
So, which one is it?
|Re: [google-appengine] Re: the min instace time is 24 hours?||Jon McAlister||9/6/11 7:06 AM|
Let me summarize the case you describe, to make sure I get it right.
It helps here to refer to the billing formula to understand this.
billable-instances-rate = min(active-instances-rate +
So, for time period [0:5], this expression evaluates to min(4+1,4)=4,
"Phew": Charged for 5 minutes of 4 instances, followed by 15 minutes
|Re: [google-appengine] Re: the min instace time is 24 hours?||Simon Knott||9/6/11 7:14 AM|
Thanks for the description Jon, that clears up a lot of my misunderstanding!
|Re: [google-appengine] Re: the min instace time is 24 hours?||Jon McAlister||9/6/11 7:15 AM|
Glad to hear!
On Tue, Sep 6, 2011 at 7:14 AM, Simon Knott <knott...@gmail.com> wrote:
> --> To view this discussion on the web visit
|Re: [google-appengine] Re: the min instace time is 24 hours?||Dani Shaulov||9/6/11 8:45 AM|
But the instance does not go away.
I have a small app. I uploaded and entered the url once, an instance spun up.
I the did not enter the web site for a whole day.
After a day I entered my admin console expecting to see 0 instances.
But what i saw was 1 with an age of a full day.
Now the question is - will this be counted as 24 instance hours?
Even though it was active for 5 minuets and idle for 24 hours minus 5 minuets?
Is there a bug in the scheduler preventing it form killing a lonely idle instance after 15 minuets of idling?
Is this how it's supposed to work.
(btw I cannot check billing history for that day as it was only yesterday and history lags 3 days behind)
|Re: the min instace time is 24 hours?||Tammo Freese||9/6/11 8:48 AM|
thanks for your clarification! I like the "Phew" scenario a lot. :)
Could you please clarify the following points:
1) My scenario included the 4 instances to be fired up be the traffic
spike. As I understand http://code.google.com/appengine/kb/postpreviewpricing.html#time_granularity_instance_pricing
there is a startup fee of 15 minutes for each instance.
- Is that startup fee covered by the instance idling for 15 minutes
- If I understand your calculation correctly, by setting max-idle-
instances to 1 I can basically pay the startup fee for one instance
2) For the time period [20, inf] you wrote that total instances is 0.
Is it guaranteed that instances die after being idle for 15 minutes?
- Then the example of the FAQ would be misleading, because it mentions
an instance that "stops and then starts", and "serving traffic for 5
min, is then down for 4 minutes and then serving traffic for 3 more
minutes" – the instance would not stop or start or be down, but just
- What's the sense of being able to set max-idle-instances then, if
they die anyway? Nothing would change by setting the value higher
(except for the hours billed).
- How can we prevent the scheduler from leaving an idle instance
around for the whole day? Because we can't set max-idle-instances to
0, we would have to pay for that.
|Re: [google-appengine] Re: the min instace time is 24 hours?||Jon McAlister||9/6/11 9:40 AM|
I assume you are talking about 'drag-2-share' here? Even if the
It would be reasonable for us to physically kill off such instances
> --> https://groups.google.com/d/msg/google-appengine/-/IY3SH_AQ2PMJ.
|Re: [google-appengine] Re: the min instace time is 24 hours?||Jon McAlister||9/6/11 9:49 AM|
} there is a startup fee of 15 minutes for each instance.
This only affects the computation of the total-instances variable
} - If I understand your calculation correctly, by setting max-idle-
} Is it guaranteed that instances die after being idle for 15 minutes?
They will usually die before 15 minutes [see other response], but
} - What's the sense of being able to set max-idle-instances then, if
Death is based on units of time, but max-idle-instances is
} Nothing would change by setting the value higher
The max-idle-instances setting has two effects. The first is a
So, if you had an app with hundreds of instances, and set
> To post to this group, send email to google-a...@googlegroups.com.
|Re: [google-appengine] Re: the min instace time is 24 hours?||Dani Shaulov||9/6/11 10:29 AM|
Thank you Jon.
It makes much more sense now.
If an instance starts - active for 1 seconds
Then idle for 5 and again active for 1 second
And again 1 second active every 5 minuets of idle
(basically 1 request (which takes 1 second) every 5 minuets)
So it is a total of 288 active seconds a day.
Is that charged as 15 min start up fee + 288 seconds,
or as 24 hours of instance time?
In my understanding, in the old model it's the former and in the new model it's the latter.
Is that right?
|Re: [google-appengine] Re: the min instace time is 24 hours?||Deepak Singh||9/6/11 11:31 AM|
Suppose, i have set my max-idle-instance to 0. And i have written a cron job which actually does nothing. It just call the servlet method and finishes.
Thus it is able to create a new instance. I run this cron job every minute.
In this case i get almost always one instance live and iahe set to max-idle-instance to 0.
So, how does it affect the billing where i set max-idle-instance to 1.
--To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/lPvp44U3uLgJ.
|Re: [google-appengine] Re: the min instace time is 24 hours?||Jon McAlister||9/6/11 11:31 AM|
If you have set max-idle-instances=1, then in that example, what would
(a) Instance is active 1 second every 5 minutes.
So the total billable instances for the day would be 24, which happens
|Re: [google-appengine] Re: the min instace time is 24 hours?||Jon McAlister||9/6/11 11:33 AM|
It is not possible to set max-idle-instances to 0. If you had set
|Re: [google-appengine] Re: the min instace time is 24 hours?||Deepak Singh||9/6/11 11:38 AM|
In case i have min-idle-instance = 0
Max-idle-instance = 1 Or Automatic
and i run the cron job as stated earlier. Then how does it affect the bill as cron job does not do anything means does not use any resources.
|Re: [google-appengine] Re: the min instace time is 24 hours?||Jon McAlister||9/6/11 11:42 AM|
I probably don't understand your example perfectly. I think you are
saying that the app only runs a cron job request once a minute, that
request does nothing, and the app has absolutely no other traffic.
In that example, if max-idle-instances=1, then the billable instance
|Re: [google-appengine] Re: the min instace time is 24 hours?||Deepak Singh||9/6/11 12:03 PM|
My question is the difference between,
set min-idle-instance to 0 and run a cron job every min or every 15 min to ensure that at least one instance is available.
And i have set max-idle-instance to either 1 or Automatic.
The App may have or may not have traffic.
|Re: [google-appengine] Re: the min instace time is 24 hours?||Jon McAlister||9/6/11 12:17 PM|
I'm sorry Deepak, but I just don't understand your question. Perhaps
someone else understands the point he is trying to raise, and can help
|Re: [google-appengine] Re: the min instace time is 24 hours?||barryhunter||9/6/11 12:40 PM|
Maybe it's a request to have a min-idle-instance setting added?
because that doesn't exist yet...
|Re: [google-appengine] Re: the min instace time is 24 hours?||Deepak Singh||9/6/11 12:51 PM|
yes exactly. I have set min-idle-instance to 0.
but i want that at least one instance should be available every time, so i set up a cron job for every min.
So does it make any difference in billing between these two ways?
Also, One more question,
I am using java GAE.
We have static block and instance block concept in java. Instance block gets called whenever we create a new object of that class And static block is called when that class gets loaded to the server.
So in case of GAE, when a new instance is created for the application, does it invoke instance block or static block while creating the instance ?
Based on this process, we need to write our logic of application. So i need to understand it.
|Re: [google-appengine] Re: the min instace time is 24 hours?||Jon McAlister||9/6/11 1:57 PM|
Those will have the same bill, yes. The ability to configure
min-idle-instances will be enabled once the billing rollout is
|Re: [google-appengine] Re: the min instace time is 24 hours?||Tim||9/7/11 2:07 AM|
Thanks for that explanation, but if it's authoritative (not meaning to sound rude, but I hope .. I take it you're on the AppEngine team rather than a user explaining your understanding of how pricing applies) then it perhaps illustrates what many of us may be worried about, and maybe a more detailed explanation of the scheduler and 15-minute rule may put some minds at rest and reduce some of the hostility to the new billing scheme.
It's the sort of thing that can be easily explained in person, but can be hard to get across on paper, so let me explain how I may have previously got the wrong impression and been more alarmed than you may consider seems appropriate.
Everything I've read about the "15 minute minimum instance" would imply in the above scenario described that the billing would be
Time Period: [0:5] - 4 active instances
Time Period [5:20] - 4 active instances running for their 15 minute minimum idle time since last query
Time Period [20:inf] - 0 active instances (ie some of the above may still be idling awaiting being killed, but wouldn't be billed)
This would give a charge of 80 minutes, as opposed to 35 as explained by yourself - I might have set min-idle-instances to 1, but I understood that once an instance was started it would be charged for instance time until 15 minutes after it's last activity.
Now I'm willing to take it that you're right, but the pricing as explained so far has led me to believe that the rule is
- ANY instance, once started, will not be eligible to be killed until at least 15 minutes after last activity, and thus will lead to at least 15 minutes billing each
- Instances will be started up according to traffic demands
- Instances will be killed off when the number of "instances that have each gone BEYOND their 15 minutes since their last activity" exceeds "max-idle-instances"
And the thing that worried me about the above understanding was that if, in the period [5:20], there were a few queries (say 1 query a minute) then the scheduler might hand these round-robin style to the 4 idling instances, thereby keeping 4 instances active for much longer, rather than giving them repeatedly to the same single instance and thereby killing instances 2,3 and 4 at the 20 minute mark.
This is what was alarming me - the impression that, given the odd short burst of traffic (say a busy minute once every couple of hours) that started up a handful of extra instances, then the scheduler might keep all these instances hanging around for ages, each running mostly idle but sharing the "normal load", and thus leading to a massive bill following each burst no matter how short.
Now you seem to be saying that this reading is incorrect (to which I and many others may understandably say "phew!") and the rules are more like
- Instances, once started, are kept in a list ordered by start time
- Any activity causes the list to be checked in order (ie first started checked first) for a free active instance, and assigned to the first one that is idle
- If none are idle, the query will be queued up to "max-pending" time to see if any instance becomes free before a new instance is started
- Each time an instance in the list finishes serving a query, the scheduler checks how many instances are actually busy, and if the number exceeds max-idle-instances, then it chooses instances from the END of the list (most recently started) to kill (or logically killed as in stopped being billed and removed from the list)
- 15 minutes after any instance last serviced a query, it is killed (or logically...) regardless of max-idle-instances unless that would breach min-idle-instances
Now I'd understand if the above has approximations (eg extra pauses in the above), or has got some details wrong, or you don;t want to commit to PRECISELY how it works so you can change it in future and in fact what happens is you don't do all these checks in realtime (other than choosing what instance to assign etc) but then apply the logic afterwards for billing purposes (ie you tend to err on keeping things active in case they're needed, but bill as if they'd been killed off according to the rule above).
But if scheduling (of queries to instances), and billing (of instance time) is closer to explanation #2 than #1, then I could probably live with the "15 minute" rule, but I'd hope you could also see that if the scheduler works more like #1 than #2 then that would be why so many of us are worried about "15 minutes" and would like to see that interval dropped to more like "2 minutes" !
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.
|Re: [google-appengine] Re: the min instace time is 24 hours?||John||9/7/11 4:08 AM|
There is an issue currently that the billing history comparison does not work like whatever Jon describes - and it may be because of the 3 resident instances.
For example with my 3 resident instances being almost idle 100% of the day, I still get a comparison bill which includes 3x24 hours resident instances every day with max idle instance=1 (should be billable under free quota according to Jon).
I understand we will not be able to test the min idle instance setting until the new billing gets rolled out - and the current billing comparison is not really what we'll get on this particular case. Or maybe what Jon describes as theory is not what happens in practice.
Until we can set min idle instances, we will not be able to confirm that what Jon describes is actually what happens.
My 2 cents is that we're still in it for lots of surprises given the overall confusion and contradictory user reports (not accounting for the new bugs found relating to the scheduler).
|Re: the min instace time is 24 hours?||Tammo Freese||9/7/11 7:20 AM|
On Sep 6, 6:49 pm, Jon McAlister <jon...@google.com> wrote:
> } there is a startup fee of 15 minutes for each instance.
> This only affects the computation of the total-instances variable
> in the formula, it does not affect the computation of
so total-instances is the maximum of active-instances over the last 15
> } Is it guaranteed that instances die after being idle for 15 minutes?
> They will usually die before 15 minutes [see other response], but
> it is possible they may live past 15 minutes of idleness. But
> past 15 minutes of idleness, they are completely ignored by the
> billing system.
Let's say I have 4 active instances for 5 minutes, then no traffic for
the rest of the day, max-idle-instances set to 1.
1) 35 minutes will be billed regardless when the scheduler decides to
kill idle instances, right?
2) But 1 instance would be idle for at least 15 minutes, right?
> The max-idle-instances setting has two effects. The first is a
> hint to the scheduler to kill off excess idle instances [it does
> this now, but approximately], and the second is how it is used in
> the billing formula.
Let's say I have 4 active instances for 5 minutes, then no traffic for
the rest of the day, max-idle-instances set to 4.
1) 80 minutes will be billed regardless when the scheduler decides to
kill idle instances, right?
2) But 4 instances would be idle for at least 15 minutes, right?
Take care and thanks for your help,
|Re: [google-appengine] Re: the min instace time is 24 hours?||Jon McAlister||9/7/11 7:46 AM|
On Wed, Sep 7, 2011 at 2:07 AM, Tim <mee...@gmail.com> wrote:
Correct. Correct. Correct.
> Everything I've read about the "15 minute minimum instance" would imply in
This characterization of the imprecise nature of the implementation of
> But if scheduling (of queries to instances), and billing (of instance time)
Understood. And again, apologies. We mean well, we messed up, we're
> An authoritative explanation of the intent (there's that word again Greg) of
Agreed. The system is large and complex, its hard to understand and
|Re: [google-appengine] Re: the min instace time is 24 hours?||Jon McAlister||9/7/11 7:49 AM|
On Wed, Sep 7, 2011 at 7:20 AM, Tammo Freese <in...@flockofbirds.net> wrote:
Not really, no.
> 2) But 1 instance would be idle for at least 15 minutes, right?
> 2) But 4 instances would be idle for at least 15 minutes, right?
> To post to this group, send email to google-a...@googlegroups.com.
|Re: the min instace time is 24 hours?||Tammo Freese||9/7/11 8:56 AM|
again, thanks for your answer, and sorry for bothering you with new
questions. This would be so much easier in face-to-face conversation
than with email. If you would like a Google hangout, just drop me an
On Sep 7, 4:49 pm, Jon McAlister <jon...@google.com> wrote:
> On Wed, Sep 7, 2011 at 7:20 AM, Tammo Freese <i...@flockofbirds.net> wrote:So what is total-instances then? I know, that sounds like a dumb
question. At first assumed that in second x, it would simply be the
number of instances (active+idle) in that second (total instances as I
understand it). But in one of your posts, you wrote "total-instances
refers to the blue line on the graph, and is computed according to the
So setting max-idle-instances to 4 leads to being reliably billed
more, but not having any reliable way of measuring the benefit?
|Re: [google-appengine] Re: the min instace time is 24 hours?||Tim||9/7/11 9:02 AM|
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.
|Re: [google-appengine] Re: the min instace time is 24 hours?||Jon McAlister||9/7/11 9:15 AM|
On Wed, Sep 7, 2011 at 9:02 AM, Tim <mee...@gmail.com> wrote:
I'm really glad to hear that!
> I know how hard it can be to explain such things without leaving room for
I think that is an excellent idea.
> I'm willing to accept that the scheduler is always going to making guesses,
Exactly. The other thing that happens is that this imprecision allows
> So, based on that understanding of what you're doing, I'm going to take the
Glad to hear!
> To view this discussion on the web visit> https://groups.google.com/d/msg/google-appengine/-/guF1P8yyofkJ.
|Re: [google-appengine] Re: the min instace time is 24 hours?||Jon McAlister||9/7/11 9:19 AM|
On Wed, Sep 7, 2011 at 8:56 AM, Tammo Freese <in...@flockofbirds.net> wrote:
Right. The way the total-instances-rate (the blue line) is computed is
The benefit should be visible in terms of average serving latency and
> To post to this group, send email to google-a...@googlegroups.com.
|Re: the min instace time is 24 hours?||Tammo Freese||9/7/11 11:09 AM|
On Sep 7, 6:19 pm, Jon McAlister <jon...@google.com> wrote:
> On Wed, Sep 7, 2011 at 8:56 AM, Tammo Freese <i...@flockofbirds.net> wrote:could you please give us the algorithm how total-instances is
The graph aggregates values. Because of that, it does not help much to
understand what's going on. For example, the current graph (6 hours)
does never show more than 1 active instance, but I currently I see two
instances handling requests. Total instances goes up to around 5 and
even spikes once to 8, but from the graph I can't figure out why that
happens. There is even one point in the graph where Total goes down
below Active (!).
|unk...@googlegroups.com||9/7/11 6:21 PM||<This message has been deleted.>|
|unk...@googlegroups.com||9/7/11 7:02 PM||<This message has been deleted.>|
|Re: the min instace time is 24 hours?||Tammo Freese||9/8/11 11:11 PM|
sorry to hassle you again. Her is an example:
An app gets a 5 minute traffic spike at the start of each hour,
leading to four instances being active the entire five minutes. Then,
the app gets
no more traffic for the rest of the hour. max-idle-instances is set to
1. That's basically the scenario described in
but with traffic each hour instead of once a day.
From (1), I would estimate the billed minutes to be 35 * 24 = 840 (14
hours), so the app would be within free quota.
Looking at (2), I come up with 32 hours:
(a) 4 instances are active 5 minutes every hour.
(b) That is 5*60*4*24 = 28,800 active seconds for the day.
(c) active-instances-rate is = 28,800/60*60*24 = 0.3333
(d) total-instances-rate = 20*60*4*24/60*60*24 = 1.3333 (total
instances should be 4 for the 5 minutes spikes + 15 minutes after the
(e) billable-instances-rate = min(active-instances-rate +
max-idle-instances, total-instances-rate) = min(0.3333 + 1, 1.3333) =
1.3333 (32 hours)
Which of the solutions is right, and what have I done wrong at the
|Re: the min instace time is 24 hours?||Tammo Freese||9/8/11 11:13 PM|
|Re: [google-appengine] Re: the min instace time is 24 hours?||Rishi Arora||9/9/11 4:32 AM|
Btw, I have a suggestion for you in optimizing for the 5 minute hourly spike you experience. If you want to always ever have only a single instance, and can tolerate high latencies during that 5 minute window every hour, what you can do is use pull mode task queues. In that 5 minute window, all your requests can be queued up in a pull queue (call it the spike queue). Then your single instance leases these requests one at a time, and processes them one at a time. If your "MaxInstances" parameter is set to 1, and this single instance is busy serving the spike at the start of the hour, your other requests might get delayed. To fix that you can put all other requests in a different pull queue - call it the high priority pull queue. Your single instance should now check for entries in the high priority pull queue after processing every entry in the spike queue. So your regular requests will at most incur a latency of however long it takes to process a single request in the spike queue.
Hope this helps.
On Fri, Sep 9, 2011 at 1:13 AM, Tammo Freese <in...@flockofbirds.net> wrote:
Missing in the last post:
|Re: [google-appengine] Re: the min instace time is 24 hours?||Jon McAlister||9/9/11 8:36 AM|
(1) is correct. (2) is wrong because it is assuming things are the
same all day long which is not true in your example, in your example,
there are three kinds of minutes, the [0:5] range, the [5:20] range,
and the [20:60] range. The three ranges need to be computed
independently (as the billing formula would) which yields 14 instances
hours (and thus free).
|RE: [google-appengine] Re: the min instace time is 24 hours?||Brandon Wirtz||9/9/11 10:25 AM|
If the scheduler worked right there wouldn't be the insane number of Idle
instances. Even if there is a 1/12 of the time that runs at 12x the volume
should look like:
So the average should be 4x mode.
As I see it there is no reason to need a "Max Idle Instances" only a "max
Spin Up: If Queue is > Max Que Spin up new instance.
This is how every load balancer / Cloud balancer on the planet works (except
If CPU % On Current Instance > X
Since App Engine isn't parallel Rather than CPU Load, you look at Serial
A good scheduler would be multi-pass, if you have a "problem customer" (one
I still see the problem with the scheduler being that we are not specifying
It's a good point. The most simple advice I'd have for you is to follow this
(1) If you're unhappy with the cost, reduce max-idle-instances.
I think that's really all that most developers should need to do.
There are also lots of optimizations that could made to any app (e.g.
On Wed, Sep 7, 2011 at 6:21 PM, Vivek Puri <v...@vivekpuri.com> wrote:
|Re: the min instace time is 24 hours?||Tammo Freese||9/9/11 10:40 AM|
thanks, it is great to hear that!
|Re: [google-appengine] Re: the min instace time is 24 hours?||Jon McAlister||9/9/11 11:33 AM|
Correct, resident instances (those from always-on or
min-idle-instances) are billed differently than dynamic instances. A
resident instance is always assumed to be active, although it does not
show up on the active-instances-graph, which is confusing.
> To view this discussion on the web visit> https://groups.google.com/d/msg/google-appengine/-/aK7utTL6nOQJ.