The Unofficial Google App Engine Price Change FAQ

270 views
Skip to first unread message

Jeff Schnitzer

unread,
Sep 9, 2011, 8:05:32 PM9/9/11
to Google App Engine

Ikai Lan (Google)

unread,
Sep 9, 2011, 8:33:46 PM9/9/11
to google-a...@googlegroups.com
Thanks for this, Jeff!

But dude, grey on black?!

--
Ikai Lan 
Developer Programs Engineer, Google App Engine




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


Steve Sherrie

unread,
Sep 9, 2011, 8:40:43 PM9/9/11
to google-a...@googlegroups.com
I was thinking the same! Looks lovely but after concentrating on the <p> text, those headings were painfully bright :)

Great job though! Great explanation of everything.


Steve

Steve

unread,
Sep 9, 2011, 9:29:46 PM9/9/11
to google-a...@googlegroups.com
Thanks for the good FAQ.  I have to strenuously disagree though with calling all the scheduler complaints a red herring.

It's legitimate complaint and mindbogglingly simple to fix by giving users a control called Max-Instances instead of Max-Idle-Instances.  Right now we have to play all these stupid tuning games to keep the scheduler from fanning things out in unsustainable ways.  If we could just set a hard limit we could make sure it never fanned out past a certain level of instance parallelism.  It's such a freaking easy thing to fix but Google doesn't want to do that for whatever internal reason.

Sigh...

Jeff Schnitzer

unread,
Sep 9, 2011, 9:53:58 PM9/9/11
to google-a...@googlegroups.com
My point is that no adjustment to the scheduler will ever really solve
the problem. To the extent that it limits your bill, it does so by
sacrificing user experience. Sure you might prevent a second instance
from starting but that just means some poor sod is sitting around
waiting for his browser to load.

The solution to this is multithreading. Hard stop.

Jeff
PS Fixed the colors... still getting used to tumblr.

> --
> 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/-/9YEEiFuJsRUJ.

Robert Kluin

unread,
Sep 10, 2011, 12:28:13 AM9/10/11
to google-a...@googlegroups.com

Hey Jeff,
  Nice writeup.

  Out of curiosity, have you noticed decreased capacity on your multi threaded front-ends since they reduced the CPU (now 600mhz) and memory (now 128mb) / front-ends?

Robert


Jeff Schnitzer

unread,
Sep 10, 2011, 12:36:16 AM9/10/11
to google-a...@googlegroups.com
On Fri, Sep 9, 2011 at 9:28 PM, Robert Kluin <robert...@gmail.com> wrote:
>
>   Out of curiosity, have you noticed decreased capacity on your multi
> threaded front-ends since they reduced the CPU (now 600mhz) and memory (now
> 128mb) / front-ends?

I really haven't been paying attention - working on a new product. I
don't even look at the dashboard stats for the old ones anymore... and
it's been a while since any of my Java apps have had enough traffic
that I would really notice.

Jeff

Steve

unread,
Sep 10, 2011, 3:40:28 AM9/10/11
to google-a...@googlegroups.com
I would much rather specify a hard limit for number of active instances so my app scales up to that point and then degrades progressively. At that point the limit is reached, latencies would increase with increasing traffic, but if I was smart I would have set the limit so the higher traffic would not be able to exhaust my budget because instances stop increasing.  So if 30 instances worth of users were hammering my 10 hard limited instances, their browser loads would be unpleasant, but the site wouldn't go completely offline.

The current reality is that I can only limit idle instances.  As active traffic increases, the scheduler can spin up and actually exhaust my budget.  So browser latencies would be nicer for a bit, but then suddenly hit a brick wall.  After my budget is exhausted, now I've got 30 instances worth of users all hammering 1 single remaining instance.  For all intents, my site is offline.  In fact, if my budget is exhausted, I think it will go completely offline perhaps running 0 instances but definitely not able to do datastore operations.

That's not a red herring.  It's legitimately needing a way to limit performance scaling so costs stay within a manageable budget.

Tim

unread,
Sep 10, 2011, 9:14:37 AM9/10/11
to google-a...@googlegroups.com

Quote: In addition, there is a 15-minute charge ($0.02) every time an instance starts....

Sorry to keep banging on about this, but see the latest explanations of how the pricing works... what you report here is what we all heard, but it's not true.

A maximum number of "max-idle-instances" have a 15-minute charge every time they start up (in return for which they'll stay in memory for at least 15 minutes) but any instances beyond that count do NOT have a 15-minute charge for starting up, they are charged only for the time they are actively serving requests (subject, I expect, to some granularity in the billing system, but this should be considerably less than 15 minutes).

If you have max-idle set to 1, and a 1 minute massive burst meant that 100 instances were started, but then the traffic died back to nothing, then only 1 of those instances would have the 15 minute charge (and would be effectively guaranteed to stay in memory that long) - the scheduler may even decide, if the machines are not needed for other apps and there's spare capacity, to keep some or many of the 100 instances in memory (there may be another burst), but even if it does so, you're not paying for the other 99 being idle - it's what I termed the "free-idle" state.

Cheers

--
Tim

Joshua Smith

unread,
Sep 10, 2011, 9:32:57 AM9/10/11
to google-a...@googlegroups.com
Thanks, Tim.

I think that's the first clear description I've read of this particular billing phenomena.

Google overlords: Add those two paragraphs to your official docs!

--
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/-/wFY7XNN8yzsJ.

Tim

unread,
Sep 10, 2011, 11:29:24 AM9/10/11
to google-a...@googlegroups.com

On Saturday, 10 September 2011 14:32:57 UTC+1, Joshua Smith wrote:
Thanks, Tim.

I think that's the first clear description I've read of this particular billing phenomena.

Google overlords: Add those two paragraphs to your official docs!


You're welcome, see also my post here of my new understanding of the 15 minute rule (after discussions in others threads and answers from Jon), which was then confirmed as broadly accurate by the Googlers involved

  https://groups.google.com/d/topic/google-appengine/zuRXAphGnPk/discussion

 Cheers

--
T

Joshua Smith

unread,
Sep 10, 2011, 11:31:56 AM9/10/11
to google-a...@googlegroups.com
Yeah, I saw that.  But there was so much detail that it got a little hard to keep track of.

--
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/-/0kwURglI0QgJ.

GAEfan

unread,
Sep 10, 2011, 11:46:47 AM9/10/11
to Google App Engine
Nicely done, Jeff. Thank you for the succinct explanation.

Jeff Schnitzer

unread,
Sep 10, 2011, 2:30:13 PM9/10/11
to google-a...@googlegroups.com
Is this really true, that if you burst to 100 instances you won't get
the 15-minute charges? Even if you have it set to "automatic"? I'd
like to hear an official voice on this matter.

I updated the FAQ with a link to your explanation. Although I have to
admit that i'm still somewhat confused about when the 15-minute charge
will apply.

Jeff

> --
> 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/-/wFY7XNN8yzsJ.

Jeff Schnitzer

unread,
Sep 10, 2011, 2:38:40 PM9/10/11
to google-a...@googlegroups.com
Ok, I understand what you want, and perhaps that makes sense... but
this isn't really relevant to the price change. The curent behavior
of GAE is to provide best-quality service until your budget runs out,
then fail. The post-change behavior will be the same.

And really, any benefit you get from this will be statistical noise
compared to the benefit you'll get by turning on multithreading. If
each instance can serve 10 concurrent requests, this means you need
one tenth the number of instances. If you want to reduce your
instance charges, This Is The Answer, Period.

Jeff

> --
> 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/-/K_KO68dzq1UJ.

JH

unread,
Sep 10, 2011, 3:15:24 PM9/10/11
to Google App Engine
I'm very curious if the 15 minute charge in fact only applies to
instances beyond your max idle instances....Any official word?

Robert Kluin

unread,
Sep 10, 2011, 3:16:28 PM9/10/11
to google-a...@googlegroups.com
I would also like to hear an official clear explanation of this. I've
seen various conflicting answers on this, and all of the published
docs I've seen indicate Jeff's initial assessment is correct.


Robert

Gerald Tan

unread,
Sep 10, 2011, 11:46:43 PM9/10/11
to google-a...@googlegroups.com
The way I understand it, we are being charged Max Idle Instance + Active Instance. So if we are not charged for extra Instances being spun up beyond the Max Idle Instance, then I don't think we can be charged for the 15 minutes.

I believe the 15 minutes charge applies in 2 cases:
- Backend Instances
- When the number of Total Instance drops below Max Idle Instance (rare, but it happens), it will take 15 minutes before reduced charges kick in

My guess is people have been seeing the 15 mins spin up charge for Backend Instances and assumed the same thing is charged for Frontend Instances.

Tim

unread,
Sep 11, 2011, 6:13:36 AM9/11/11
to google-a...@googlegroups.com

On Saturday, 10 September 2011 19:30:13 UTC+1, Jeff Schnitzer wrote:
Is this really true, that if you burst to 100 instances you won't get
the 15-minute charges?  Even if you have it set to "automatic"?  I'd
like to hear an official voice on this matter.

See Jon McAlister's detailed explanations of billing for particular scenarios in this thread

   the min instace time is 24 hours?

and my followup based on his answers, which he then confirms as accurate (which you've linked to your FAQ now but I repeat here for others)

  "15 minutes idle" - my new understanding of how it works

and to quote Jon when someone asked about instances being started


  In any event [...] this is why max-idle-instances is important. It
  ensures that you are not held accountable for scheduler behaviors such
  as these listed. When you set it, the billable-instances-rate is
  determined by max-idle-instances (a setting you directly control) and
  active-instances-rate (again, hopefully something you control). The
  nuances of how the scheduler spins up extra instances to minimize
  latency and provide spare capacity are not part of the formula, other
  than their effect on your serving latency and reliability

Now I don't know what would happen if max-idle-instances was set to "automatic", whether this means "1" (no you wouldn't be billed"), "infinity" (yes you'd be billed for all 100), some kind of dynamic adjustment (you might be billed for some of them depending on how many idle instances have typically been needed to run your app is the previous hours/days/month) or what... but I think "automatic" is for heavy traffic sites who always have loads of active instances, but that's why my explanations talk about having set max-idle-instances to a distinct number.
 
--
T

Gregory D'alesandre

unread,
Sep 11, 2011, 10:41:11 PM9/11/11
to google-a...@googlegroups.com
This is the official word:

You are only charged the 15 minute idle time for the number if idle instances up to your max idle instances.  So, if you have 200 instances spin up for 10 minutes and then all traffic stops and your max idle instances is set to 5.  You would be charged for (200 * 10/60 * $0.04) + (5 * 15/60 * $0.04).  The first part is the "active" instances you are charged for and the second is the "idle" instances you are charged for.  Even if all 200 instances stick around for 10 hours, you will still only be charged for what I listed.

I hope that helps clarify.  We are working on updating our docs to make this more clear.  Sorry for the confusion.

Jeff, awesome work on that post.

Thanks and let me know if you have additional questions!

Greg

Jon McAlister

unread,
Sep 12, 2011, 1:16:51 PM9/12/11
to google-a...@googlegroups.com
Yep, Tim is right. Thanks again Tim for reformulating the logic and
making it easy to understand.

} Now I don't know what would happen if max-idle-instances was set
} to "automatic", whether this means "1" (no you wouldn't be
} billed"), "infinity" (yes you'd be billed for all 100),

Right now it's the latter. If max-idle-instances is set to automatic
then it is assumed to be infinity.

> --
> 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/-/XJNxgBKeTfEJ.

Reply all
Reply to author
Forward
0 new messages