FAQ for out of preview pricing changes

9,082 views
Skip to first unread message

Gregory D'alesandre

unread,
May 18, 2011, 12:49:30 AM5/18/11
to google-a...@googlegroups.com
Hello All!

As you've likely heard, when Google App Engine leaves Preview in the second half of 2011, the pricing model will change.  Prices are listed here: http://www.google.com/enterprise/appengine/appengine_pricing.html.  But that leaves a lot of questions unanswered, this FAQ is intended to help answer some of the frequently asked questions about the new model.  We are interested in hearing additional thoughts and comments you have based on this.  Once it is relatively stable I'll add it to our official docs.  If you find there is something you want to know but it is not yet answered, just ask and I'll try to answer it as clearly as possible.  We've made some changes based on the feedback we've gotten (from this group in particular), they are bolded below but not updated on the external pages yet.  There are still blanks to fill in and I will be sending that information to this group first in order as it is available.  Finally, thank you for your questions and bearing with us as we are ironing out details, I and the whole App Engine team very much appreciate it.

Greg D'Alesandre
Senior Product Manager, Google App Engine

-------------------

Definitions
Instance: A small virtual environment to run your code with a reserved amount of CPU and Memory.
Frontend Instance: An Instance running your code and scaling dynamically based on the incoming requests but limited in how long a request can run.
Backend Instance: An Instance running your code with limited scaling based on your settings and potentially starting and stopping based on your actions.
Scheduler: Part of the App Engine infrastructure that determines which Instance should serve a request including whether or not a new Instance is needed.

Serving Infrastructure
Q: What’s an Instance?
A: When App Engine starts running your code it creates a small virtual environment to run your code with a reserved amount of CPU and Memory.  For example if you are running a Java app, we will start a new JVM for you and load your code into it.

Q: Is an App Engine Instance similar to a VM from infrastructure providers?
A: Yes and no, they both have a set amount of CPU and Memory allocated to them, but GAE instances don’t have the overhead of operating systems or other applications running, so a much larger percentage of the CPU and memory is considered “usable.” They also operate against high-level APIs and not down through layers of code to virtual device drivers, so it’s more efficient, and allows all the services to be fully managed.

Q: How does GAE determine the number of Frontend Instances to run?  
A: For each new request, the Scheduler decides whether there is an available Instance for the request, the request should wait, or a new Instance should be created to service the request.  It looks at the number of Instances, the throughput of the Instances, and the number of requests waiting.  Based on that it predicts how long it will take before it can serve the request (aka the Pending Latency).  If it predicts the delay will be over 1 second, a new Instance is created.  If it looks like an Instance is no longer needed, it will take that Instance down.  

Q: Should I assume I will be charged for the number of Instances currently being shown in the Admin console?
A: No, we are working to change the Scheduler to optimize the utilization of instances, so that number should go down somewhat.  If you are using Java, you can also make your app threadsafe and take advantage of handling concurrent requests.  You can look at that as an upper bound on how many Instances you will be charged for.

Q: How can I control the number of instances running?
A: With the new Scheduler you’ll have the ability to choose a set of parameters that will help you specify how many instances are spun up to serve your traffic.  More information about the specific parameters and how they will affect the Scheduler will be available on this within a few weeks.

Q: What can I control in terms of how many requests an Instance can handle?
A: The single largest factor is your application’s latency in handling the request.  If you service requests quickly, a single instance can handle a lot of requests.  Also, Java apps support concurrent requests, so it can handle additional requests while waiting for other requests to complete.  This can significantly lower the number of Instances your app requires.

Q: Will there be a solution for Python concurrency?  Will this require any code changes?
Python concurrency will be handled by our release of Python 2.7 on App Engine.  We’ve heard a lot of feedback from our Python users who are worried that the incentive is to move to Java because of its support for concurrent requests, so we’ve made a change to the new pricing to account for that.  While Python 2.7 support is currently in progress it is not yet done so we will be providing a half-sized instance for Python (at half the price) until Python 2.7 is released.

Q: How many requests can an average instance handle?
A: Single-threaded Instances (python or java) can currently handle 1 concurrent request.  Single-threaded Instances (python or java) can currently handle 1 concurrent request.  Therefore there is a direct relationship between the latency and number of requests which can be handled on the instance per second, for instance: 10ms latency = 100 request/second/Instance, 100ms latency = 10 request/second/Instance, etc.  Multi-Threaded Instances can handle many concurrent requests.  Therefore there is a direct relationship between the cpu consumed and the number of requests/second.  For instance, for a B4 (approx 2.4GHz) instance: consuming 10 Mcycles/request = 240 request/second/Instance, 100 Mcycles/request = 24 request/second/Instance, etc.  These numbers are the ideal case but they are pretty close to what you should be able to accomplish on an Instance. Multi-Threaded instances are currently only supported for Java; we are planning support for Python later this year.

Q: Why is Google charging for instances rather than CPU as in the old model?  Were customers really asking for this?
A: CPU time only accounts for a portion of the resources used by App Engine.  When App Engine runs your code it creates an Instance, this is a maximum amount of CPU and Memory that can be used for running a set of your code.  Even if the CPU is not currently working due to waiting for responses, the instance is still resident and considered “in use” so, essentially, it still costs Google money.  Under the current model, apps that have high latency (or in other words stay resident for long periods of time without doing anything) are not able to scale because it would be cost-prohibitive to Google.  So, this change is designed to allow developers to run any sort of application they would like but pay for all of the resources that are being used.

Q: What does this mean for existing customers?
A: Many customers have optimized for low CPU usage to keep bills low, but in turn are often using a large amount of memory (by having high latency applications).  This new model will encourage low latency applications even if it means using larger amounts of CPU.

Q: How will always-on work under the new model?
A: Still determining how this will work, answer coming very soon (no seriously, we are almost done).

Q: What is the difference between On-demand Instances and Reserved Instances?
A: On-demand Instances have no pre-commitment in terms of the number that will be used.  You pay for them as you use them.  Reserved Instances are pre-commitment to a certain number of Instance Hours in a week.  They are cheaper but you must pay for all the Instance Hours that you have pre-committed to whether you use them or not.  This does not mean they have to be running the whole time.

Q: Wait, so Reserved instances don’t mean you have to keep them running the whole time?
A: No, it is just a way to get cheaper instance-hours by pre-committing to them.

Q: What is the time granularity of the instance pricing?  ie if I have an instance up for 5 minutes, what am I charged, $0.08 / 60*5?
A: Instances are charged for their uptime and until they are idle for 15 minutes (when the scheduler takes them down).  So if you have an on-demand Instance only serving traffic for 5 minutes, you will pay for 5+15 minutes, or $0.08 / 60 * 20 = 2.6 cents.

Q: You seem to be trying to account for RAM in the new model.  Will I be able to purchase Frontend Instances that use different amounts of memory?
A: We are only planning on having one size of Frontend Instance.

Q: Do Frontend instances handle Task Queues and Cron?
A: Yes.

Q: Can the experimental Go Runtime handle concurrent requests?
A: Not currently.

Costs
Q: Is the $9/app/month a fee or a minimum spend?
A: Based on the feedback we’ve received we are changing this $9 fee to be a minimum spend rather than a fee a originally listed.  In other words you will still have to spend $9/month in order to scale but you won’t pay an additional $9 for your first $9 worth of usage each month.  The $500/account/month will still be a fee as it covers the cost of operational support.

Q: Will most customers have to move to Paid Apps?
A: No, we expect the majority of current active apps will still fall under the free quota.

Q: Will existing apps be grandfathered in and continue under today’s billing model?
A: No, existing apps will fall under the new billing model once App Engine is out of preview.

Q: Will most customers’ bills increase? If so, why is Google increasing the price for App Engine?
A: Yes, most paying customers will see higher bills.  During the preview phase of App Engine we have been able to observe what it costs to run the product as well as what typical use patterns have been.  We are changing the prices now because GAE is going to be a full product for Google and therefore needs to have a sustainable revenue model for years to come.

APIs
Q: How were the APIs priced?
A: For the most part the APIs are priced similarly to what they cost today, but rather than charging for CPU hours we are charging for operations.  For instance the Channel API is $0.01/100 channels.  This is approximately what users pay today (although it would be paid as a fraction of a CPU hour).  The datastore API is the most significantly changed and is described below.

Q: For the items under APIs on the pricing page that just have a check, what does that mean?
A: Those items come free with using App Engine.

Q: For XMPP, how does the new model work?  How much do presence messages cost?
A: For XMPP we will only be charging an operation fee for outgoing stanzas.  Incoming stanzas are just considered requests similar to any other request and so we’ll charge for the bandwidth used as well as whatever it takes to process the request in terms of Instance Hours.  We don’t charge for presence messages other than the bandwidth it consumes.  This is almost exactly how it works today with the exception that your bill would show CPU hours as opposed to Stanzas.

Q: For Email, how much do incoming emails cost?
A: Incoming emails will just be considered requests similar to any other request and so we’ll charge for the bandwidth used as well as whatever it takes to process the request in terms of Instance Hours.  This is in essence how it works today.

Q: Will the Front End Cache feature ever be formalized as an expected, documented part of the service offering?
A: We are currently looking at various options, but don’t yet have any plans for when this would happen.

Q:  What is being charged for in terms of Datastore operations?  What do you expect the ratio to be between the new pricing metric and the Datastore API calls metric we have today?
A: Today we charge for the CPU consumed per entity written, index written, entity read, query index scanned, and query result read.  Under the new model we will charge per operation rather than CPU, and we will no longer charge for query index scans.  This means the cost of your queries will be tied exclusively to the size of your result set.  We expect the cost of these operations will be approximately 4x the cost of the equivalent CPU under today’s model, but for apps that make heavy use of indexes, this will be somewhat offset by the fact that we will no longer be charging for query index scans.  The admin console today shows total Datastore API Calls, but this is not a good gauge of how many operations you will be charged for under the new model.  Your costs will be highly dependent on the types and contents of your API calls, not the number of calls themselves, which is what we currently display.  For example a single get() API call may retrieve 1 Entity or 100 Entities, and a beginTransaction() API call doesn’t consume any billable resources.

Q: Could emails sent to admins be cheaper or free?
A: That’s a possibility that we can look into.

Usage Types
Q: What does the Premier cost of "$500/account" mean? Per Google Apps Account? Per Developer Account, Per Application Owner Account?
A: It is per Organization (which would translate into per Google Apps account if you are currently a Google Apps customer).  So, for instance if you are working at gregco.com and you signed up for a Premier account, gregco.com users will be able to create apps which are billed to the gregco.com account.

Q: Will there be special programs for non-profit usage?
A: Possibly, we are currently looking into this.

Q: Will there be special programs for educational usage?
A: Possibly, we are currently looking into this.

Q: Will there be special programs for open-source projects?
A: Possibly, we are currently looking into this.

Usage Limits
Q: If I migrate to HR Datastore, does that mean I have a "newly created" application, and will get the new, lower, free quota for email?  Could you grandfather in migrated apps at the old 2000 limit?
A: Yes, we can grandfather in the email quota for HRD apps that are migrating from M/S apps.

Robert Kluin

unread,
May 18, 2011, 1:13:03 AM5/18/11
to google-a...@googlegroups.com
Hi Greg,
I'm looking forward to seeing the scheduler improvements in the
coming weeks. Overall this looks promising, I'm actually pretty happy
to see that the API calls 'with checks' will be included and just
billed by time consumed. Is the 4x cost relative to a master-slave
(M/S) or high-replication (HR) apps? Certainly if that is relative to
M/S then it is not that bad, HR is totally worth it. ;)

Thanks for listening to and addressing the community's feedback.

Robert

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

Stephen Johnson

unread,
May 18, 2011, 1:20:15 AM5/18/11
to google-a...@googlegroups.com
Greg,
Still not clear on the datastore costs. For this you say, "This means

the cost of your queries will be tied exclusively to the size of your
result set." Is this the same whether you return just the keys (keys
only query) or also the entities. It seems like it should not be the
same since a fetch to get the whole entity is not required but I'm not
clear when you say "size of your result set." I think a lot of people
have tried to optimize some operations by just returning the keys and
not the entire entities and I hope that wasn't wasted effort.
Thanks,
Stephen

Vinuth Madinur

unread,
May 18, 2011, 2:06:36 AM5/18/11
to google-a...@googlegroups.com
"For instance, for a B4 (approx 2.4GHz) instance: consuming 10 Mcycles/request = 240 request/second/Instance, 100 Mcycles/request = 24 request/second/Instance, etc. "
&
"We are only planning on having one size of Frontend Instance."

Q: So, is a Frontend Instance going to be a B4?


"Even if the CPU is not currently working due to waiting for responses, the instance is still resident and considered “in use” so, essentially, it still costs Google money."

Q: Does this mean, the Instance is exclusive and not shared between applications? That the CPU will be left idle rather than used by another application? And the unused memory be left free rather than allowing other apps to use it?

Q: Is there ever a possibility to have different pricing for active instance hours versus idle instance hours?


Still unhappy about the $9/month pricing. And happy that we'll have python 2.7 with multi threading support by end of this year.

Thanks,
Vinuth.


--

Maxim Lacrima

unread,
May 18, 2011, 2:54:06 AM5/18/11
to google-a...@googlegroups.com
Hi!

Under the new model for the Datastore API calls, does it mean that I don't care anymore about performing operations in batches? So in terms of costs db.get(key1); db.get(key2) is essentially the same as db.get([key1, key2])?

Thank you!

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



--
with regards,
Maxim

Sudhir Jonathan

unread,
May 18, 2011, 3:23:52 AM5/18/11
to Google App Engine
Greg,

Great job with the FAQ... I think it clarifies things a lot, and is
quite will written.

I'm still not clear on some points, though.

If I do db.get([key1, key2]), and two entities were fetched, how many
'operations' have I consumed?

If key2 didn't exist and only one entity was fetched, what would be
the charges?

If db.get(key1) fetches a 5kb entity and db.get(key2) fetches a 500kb
entity, what's the difference in charges?

Under the new scheme, is it more economical to do keys only query that
fetches 1000 keys, and then do a get on the 500 of them that I need,
or just fetch all 1000 directly?

Being able to provide a definitive answer to these questions would
really help.

Sudhir
> > *Definitions*
> > *Instance*: A small virtual environment to run your code with a reserved
> > amount of CPU and Memory.
> > *Frontend Instance*: An Instance running your code and scaling dynamically
> > based on the incoming requests but limited in how long a request can run.
> > *Backend Instance*: An Instance running your code with limited scaling
> > based on your settings and potentially starting and stopping based on your
> > actions.
> > *Scheduler*: Part of the App Engine infrastructure that determines which
> > Instance should serve a request including whether or not a new Instance is
> > needed.
>
> > *Serving Infrastructure*
> > lot of requests.  Also, Java apps support concurrent requests<http://code.google.com/appengine/docs/java/config/appconfig.html#Usin...>,
> > so it can handle additional requests while waiting for other requests to
> > complete.  This can significantly lower the number of Instances your app
> > requires.
>
> > Q: Will there be a solution for Python concurrency?  Will this require any
> > code changes?
> > Python concurrency will be handled by our release of Python 2.7 on App
> > Engine.  We’ve heard a lot of feedback from our Python users who are worried
> > that the incentive is to move to Java because of its support for concurrent
> > requests, so we’ve made a change to the new pricing to account for that.
> > *While Python 2.7 support is currently in progress it is not yet done so
> > we will be providing a half-sized instance for Python (at half the price)
> > until Python 2.7 is released.*
> > *Costs*
> > Q: Is the $9/app/month a fee or a minimum spend?
> > A: *Based on the feedback we’ve received we are changing this $9 fee to be
> > a minimum spend rather than a fee a originally listed*.  In other words
> > you will still have to spend $9/month in order to scale but you won’t pay an
> > additional $9 for your first $9 worth of usage each month.  The
> > $500/account/month will still be a fee as it covers the cost of operational
> > support.
>
> > Q: Will most customers have to move to Paid Apps?
> > A: No, we expect the majority of
>
> ...
>
> read more »

Kngt

unread,
May 18, 2011, 3:28:29 AM5/18/11
to Google App Engine
Greg,

Thanks for the FAQ. A follow-up question: will datastore queries be
priced only according to the number of entities fetched/saved or will
entity size also come into play?

Thanks,
H.E.

On May 18, 7:49 am, "Gregory D'alesandre" <gr...@google.com> wrote:
> Hello All!
>
> As you've likely heard, when Google App Engine leaves Preview in the second
> half of 2011, the pricing model will change.  Prices are listed here:http://www.google.com/enterprise/appengine/appengine_pricing.html.  But that
> leaves a lot of questions unanswered, this FAQ is intended to help answer
> some of the frequently asked questions about the new model.  We are
> interested in hearing additional thoughts and comments you have based on
> this.  Once it is relatively stable I'll add it to our official docs.  If
> you find there is something you want to know but it is not yet answered,
> just ask and I'll try to answer it as clearly as possible.  We've made some
> changes based on the feedback we've gotten (from this group in particular),
> they are bolded below but not updated on the external pages yet.  There are
> still blanks to fill in and I will be sending that information to this group
> first in order as it is available.  Finally, thank you for your questions
> and bearing with us as we are ironing out details, I and the whole App
> Engine team very much appreciate it.
>
> Greg D'Alesandre
> Senior Product Manager, Google App Engine
>
> -------------------
>
> *Definitions*
> *Instance*: A small virtual environment to run your code with a reserved
> amount of CPU and Memory.
> *Frontend Instance*: An Instance running your code and scaling dynamically
> based on the incoming requests but limited in how long a request can run.
> *Backend Instance*: An Instance running your code with limited scaling based
> on your settings and potentially starting and stopping based on your
> actions.
> *Scheduler*: Part of the App Engine infrastructure that determines which
> Instance should serve a request including whether or not a new Instance is
> needed.
>
> *Serving Infrastructure*
> requests<http://code.google.com/appengine/docs/java/config/appconfig.html#Usin...>,
> so it can handle additional requests while waiting for other requests to
> complete.  This can significantly lower the number of Instances your app
> requires.
>
> Q: Will there be a solution for Python concurrency?  Will this require any
> code changes?
> Python concurrency will be handled by our release of Python 2.7 on App
> Engine.  We’ve heard a lot of feedback from our Python users who are worried
> that the incentive is to move to Java because of its support for concurrent
> requests, so we’ve made a change to the new pricing to account for
> that.  *While
> Python 2.7 support is currently in progress it is not yet done so we will be
> providing a half-sized instance for Python (at half the price) until Python
> 2.7 is released.*
> *Costs*
> Q: Is the $9/app/month a fee or a minimum spend?
> A: *Based on the feedback we’ve received we are changing this $9 fee to be a
> minimum spend rather than a fee a originally listed*.  In other words you
> will still have to spend $9/month in order to scale but you won’t pay an
> additional $9 for your first $9 worth of usage each month.  The
> $500/account/month will still be a fee as it covers the cost of operational
> support.
>
> Q: Will most customers have to move to Paid Apps?
> A: No, we expect the majority of current active apps will still fall under
> the free quota.
>
> Q: Will existing apps be grandfathered in and continue under today’s billing
> model?
> A: No, existing apps will fall under the new billing model once App Engine
> is out of preview.
>
> Q: Will most customers’ bills increase? If so, why is Google increasing the
> price for App Engine?
> A: Yes, most paying customers will see higher bills.  During the preview
> phase of App Engine we have been able to observe what it costs to run the
> product as well as what typical use patterns have been.  We are changing the
> prices now because GAE is going to be a full product for Google and
> therefore needs to have a sustainable revenue model for years to come.
>
> *APIs*
> *Usage Types*
> Q: What does the Premier cost of "$500/account" mean? Per Google Apps
> Account? Per Developer Account, Per Application Owner Account?
> A: It is per Organization (which would translate into per Google Apps
> account if you are currently a Google Apps customer).  So, for instance if
> you are working at gregco.com and you signed up for a Premier account,
> gregco.com users will be able to create apps which are billed to the
> gregco.com account.
>
> Q: Will there be special programs for non-profit usage?
> A: Possibly, we are currently looking into this.
>
> Q: Will there be special programs for educational usage?
> A: Possibly, we are currently looking into this.
>
> Q: Will there be special programs for open-source projects?
> A: Possibly, we are currently looking into this.
>
> *Usage Limits*
> Q: If I migrate to HR Datastore, does that mean I have a "newly created"
> application, and will get the new, lower, free quota for email?  Could you
> grandfather in migrated apps at the old 2000 limit?
> A: *Yes, we can grandfather in the email quota for HRD apps that are
> migrating from M/S apps.*

Brandon Wirtz

unread,
May 18, 2011, 3:30:26 AM5/18/11
to google-a...@googlegroups.com
From my FAQ:

My current provider offers me Unlimited bandwidth for $14.95 a month. How
much is your unlimited plan?

:-)

Greg,

Sudhir

--

风笑雪

unread,
May 18, 2011, 4:57:27 AM5/18/11
to google-a...@googlegroups.com
Hi Greg,

Can you raise On-demand Frontend Instances free quota to 25 Instance Hours per day?
The small apps have very low traffics in average, but sometime (maybe several minutes) it may use more than 1 instances to handle burst traffics, so that they will got OverQuotaErrors at the end of the day.

Thank you.



--

Jeff Schnitzer

unread,
May 18, 2011, 5:18:03 AM5/18/11
to google-a...@googlegroups.com
On Wed, May 18, 2011 at 1:57 AM, 风笑雪 <kea...@gmail.com> wrote:
> Hi Greg,
> Can you raise On-demand Frontend Instances free quota to 25 Instance Hours
> per day?
> The small apps have very low traffics in average, but sometime (maybe
> several minutes) it may use more than 1 instances to handle burst traffics,
> so that they will got OverQuotaErrors at the end of the day.
> Thank you.

To unofficially answer your question, I presume that one of the new
scheduler options will be "do not exceed N instances" which, if you
set N=1, will prevent you from going over free instance quota. Bursty
traffic will sit in the pending queue.

Jeff

Sylvain

unread,
May 18, 2011, 8:14:21 AM5/18/11
to Google App Engine
Thank you for this FAQ,

But : "[...] will still have to spend $9/month in order to scale but
you won’t pay an additional $9 for your first $9 worth of usage each
month.[...]"

So with this change : an app thats use 1GB above the free quota will
pay $9/month (and not $9,15) ?
Currently, this app cost $0.15/month

It's x60 than now.... more than $100 / year...

This drastic change is not fair.
I think that many small apps that don't fit within the free quotas
will be shutdown.

Regards

Sylvain
> > *Definitions*
> > *Instance*: A small virtual environment to run your code with a reserved
> > amount of CPU and Memory.
> > *Frontend Instance*: An Instance running your code and scaling dynamically
> > based on the incoming requests but limited in how long a request can run.
> > *Backend Instance*: An Instance running your code with limited scaling
> > based on your settings and potentially starting and stopping based on your
> > actions.
> > *Scheduler*: Part of the App Engine infrastructure that determines which
> > Instance should serve a request including whether or not a new Instance is
> > needed.
>
> > *Serving Infrastructure*
> > lot of requests.  Also, Java apps support concurrent requests<http://code.google.com/appengine/docs/java/config/appconfig.html#Usin...>,
> > so it can handle additional requests while waiting for other requests to
> > complete.  This can significantly lower the number of Instances your app
> > requires.
>
> > Q: Will there be a solution for Python concurrency?  Will this require any
> > code changes?
> > Python concurrency will be handled by our release of Python 2.7 on App
> > Engine.  We’ve heard a lot of feedback from our Python users who are worried
> > that the incentive is to move to Java because of its support for concurrent
> > requests, so we’ve made a change to the new pricing to account for that.
> > *While Python 2.7 support is currently in progress it is not yet done so
> > we will be providing a half-sized instance for Python (at half the price)
> > until Python 2.7 is released.*
> ...
>
> plus de détails »

Matija

unread,
May 18, 2011, 8:19:27 AM5/18/11
to google-a...@googlegroups.com
Are frontend instances paid per instance hour with or without 15 minutes charge for statup ?

Dennis

unread,
May 18, 2011, 9:23:08 AM5/18/11
to Google App Engine

> > Q: Will there be a solution for Python concurrency?  Will this require any
> > code changes?
> > Python concurrency will be handled by our release of Python 2.7 on App
> > Engine.  We’ve heard a lot of feedback from our Python users who are worried
> > that the incentive is to move to Java because of its support for concurrent
> > requests, so we’ve made a change to the new pricing to account for that.
> >  While Python 2.7 support is currently in progress it is not yet done so we
> > will be providing a half-sized instance for Python (at half the price) until
> > Python 2.7 is released.

The current answer for this question does not address the 2nd question
about code change for concurrency.
If code change is not needed, that would be great and well worth
mentioning.
If code change is needed, what changes are needed and what can we do
now to start preparing for those changes?

Dennis

unread,
May 18, 2011, 9:41:12 AM5/18/11
to Google App Engine
PS: will django apps automatically get the benefits of the python
concurrency solution?

Robert Kluin

unread,
May 18, 2011, 11:18:28 AM5/18/11
to google-a...@googlegroups.com
Hey Maxim,
Batch calls can reduce your latency allowing your app to service
requests much faster -- so batching is still going to be a good idea.
Also, be sure to check out the async db methods, they can help reduce
latency even further.

Robert

Maxim Lacrima

unread,
May 18, 2011, 11:31:04 AM5/18/11
to google-a...@googlegroups.com
Hi Robert,

Thanks for the clarification.

Andrei

unread,
May 18, 2011, 11:38:50 AM5/18/11
to Google App Engine

Why can't people write their own scheduler if the they pay for
instances

On May 18, 12:49 am, "Gregory D'alesandre" <gr...@google.com> wrote:
> Hello All!
>
> As you've likely heard, when Google App Engine leaves Preview in the second
> half of 2011, the pricing model will change.  Prices are listed here:http://www.google.com/enterprise/appengine/appengine_pricing.html.  But that
> leaves a lot of questions unanswered, this FAQ is intended to help answer
> some of the frequently asked questions about the new model.  We are
> interested in hearing additional thoughts and comments you have based on
> this.  Once it is relatively stable I'll add it to our official docs.  If
> you find there is something you want to know but it is not yet answered,
> just ask and I'll try to answer it as clearly as possible.  We've made some
> changes based on the feedback we've gotten (from this group in particular),
> they are bolded below but not updated on the external pages yet.  There are
> still blanks to fill in and I will be sending that information to this group
> first in order as it is available.  Finally, thank you for your questions
> and bearing with us as we are ironing out details, I and the whole App
> Engine team very much appreciate it.
>
> Greg D'Alesandre
> Senior Product Manager, Google App Engine
>
> -------------------
>
> *Definitions*
> *Instance*: A small virtual environment to run your code with a reserved
> amount of CPU and Memory.
> *Frontend Instance*: An Instance running your code and scaling dynamically
> based on the incoming requests but limited in how long a request can run.
> *Backend Instance*: An Instance running your code with limited scaling based
> on your settings and potentially starting and stopping based on your
> actions.
> *Scheduler*: Part of the App Engine infrastructure that determines which
> Instance should serve a request including whether or not a new Instance is
> needed.
>
> *Serving Infrastructure*
> requests<http://code.google.com/appengine/docs/java/config/appconfig.html#Usin...>,
> so it can handle additional requests while waiting for other requests to
> complete.  This can significantly lower the number of Instances your app
> requires.
>
> Q: Will there be a solution for Python concurrency?  Will this require any
> code changes?
> Python concurrency will be handled by our release of Python 2.7 on App
> Engine.  We’ve heard a lot of feedback from our Python users who are worried
> that the incentive is to move to Java because of its support for concurrent
> requests, so we’ve made a change to the new pricing to account for
> that.  *While
> Python 2.7 support is currently in progress it is not yet done so we will be
> providing a half-sized instance for Python (at half the price) until Python
> 2.7 is released.*
> *Costs*
> Q: Is the $9/app/month a fee or a minimum spend?
> A: *Based on the feedback we’ve received we are changing this $9 fee to be a
> minimum spend rather than a fee a originally listed*.  In other words you
> will still have to spend $9/month in order to scale but you won’t pay an
> additional $9 for your first $9 worth of usage each month.  The
> $500/account/month will still be a fee as it covers the cost of operational
> support.
>
> Q: Will most customers have to move to Paid Apps?
> A: No, we expect the majority of current active apps will still fall under
> the free quota.
>
> Q: Will existing apps be grandfathered in and continue under today’s billing
> model?
> A: No, existing apps will fall under the new billing model once App Engine
> is out of preview.
>
> Q: Will most customers’ bills increase? If so, why is Google increasing the
> price for App Engine?
> A: Yes, most paying customers will see higher bills.  During the preview
> phase of App Engine we have been able to observe what it costs to run the
> product as well as what typical use patterns have been.  We are changing the
> prices now because GAE is going to be a full product for Google and ...
>
> read more »

Gregory D'alesandre

unread,
May 18, 2011, 11:47:08 AM5/18/11
to google-a...@googlegroups.com
On Tue, May 17, 2011 at 10:13 PM, Robert Kluin <robert...@gmail.com> wrote:
Hi Greg,
 I'm looking forward to seeing the scheduler improvements in the
coming weeks.  Overall this looks promising, I'm actually pretty happy
to see that the API calls 'with checks' will be included and just
billed by time consumed.  Is the 4x cost relative to a master-slave
(M/S) or high-replication (HR) apps?  Certainly if that is relative to
M/S then it is not that bad, HR is totally worth it.  ;)

Good point!  It is relative to M/S.
 
 Thanks for listening to and addressing the community's feedback.

We're trying our best, thanks for hanging in there :)

Gregory D'alesandre

unread,
May 18, 2011, 11:54:43 AM5/18/11
to google-a...@googlegroups.com
There are a few questions around keys vs. entities and batch ds calls, I'll respond later today with those answers.

Greg

Gregory D'alesandre

unread,
May 18, 2011, 11:55:18 AM5/18/11
to google-a...@googlegroups.com
On Wed, May 18, 2011 at 1:57 AM, 风笑雪 <kea...@gmail.com> wrote:
Hi Greg,

Can you raise On-demand Frontend Instances free quota to 25 Instance Hours per day?
The small apps have very low traffics in average, but sometime (maybe several minutes) it may use more than 1 instances to handle burst traffics, so that they will got OverQuotaErrors at the end of the day.

Its a good point, we'll look into this.  Thanks for the suggestion!

Greg

stevep

unread,
May 18, 2011, 12:49:16 PM5/18/11
to google-a...@googlegroups.com
I have a question about structuring your on-line handlers optimally for the new scheduler algo.

Let's say your app handles 2 calls:
..callA = 10ms
..callB = 500ms

The app averages 10 callA for every 1 callB.

Average latency for 11 calls = 600ms / 11 calls

That average is heavily skewed by callB.

Will the scheduler understand this?

Or will it be better to break the calls up into two separate handlers?

thx, stevep

marcdmarc

unread,
May 18, 2011, 2:31:49 PM5/18/11
to Google App Engine
Thank you so much for the hard work clarifying the many questions that
you have been bombarded with over the past few days.

The python "multi-threading" support seems like good news, although I
am sure many would like a little more information about the plans for
python to make sure it will be the right runtime to stick with. Will
the "multi-threading" in python actually be using multiprocessing to
get around the GIL, similar to twisted web framework? Or will it use
python's epoll, similar to the tornado web framework? Or how about a
combination of both?

As Dennis mentioned above, what kind of code changes may be required?
Will webapp be getting a rewrite? Will frameworks such as twisted or
tornado work with this new "multi-threading" python runtime?

Personally, I would rather have to deal with code changes later, than
to have to port my app over to java now, but as soon as this
information is known by the Google App Engine team, it would be
beneficial for all of us python devs to know as much as we can to plan
ahead for any code changes we may have to endure later.

Best

pdknsk

unread,
May 18, 2011, 2:33:26 PM5/18/11
to Google App Engine
> Q: You seem to be trying to account for RAM in the new model.  Will I be
> able to purchase Frontend Instances that use different amounts of memory?
> A: We are only planning on having one size of Frontend Instance.

What's the reason for this? It's completely understandable if Google
wants to make (more) money. I'm just curious.

Dennis

unread,
May 18, 2011, 3:30:03 PM5/18/11
to google-a...@googlegroups.com
I looked into python multi-threading / multi-processing a bit more, especially with your tip that it requires python 2.7.

The python multiprocessing module was introduced in python 2.6
so this is probably what will be used for python appengine to get concurrency above 1 request / instance.
This solution copies and spawns processes which are heavier than threads.
I'm assuming that most of the concurrency will be achieved because processes are datastore bound: 
they are just waiting around for the datastore to return a result.

Given this type of solution (or whatever solution is used), some important questions are:
  • How many concurrent requests can a single instance handle (for python)?  If the process is waiting for the datastore, is the number of processes (and thus concurrency) dependent mainly on the number of processes that can fit in memory?
  • Will heavy python frameworks (like django) have a lower concurrency ability because they use more memory?  If so, what will their concurrent requests / instance be (for the simplest django app, then we can add in our own app's memory usage)?
  • For those considering switching to java, what is the estimated concurrent requests / instance for java apps?  Java uses threads instead of processes.


Mike Wesner

unread,
May 18, 2011, 3:50:29 PM5/18/11
to Google App Engine
Greg,

I am concerned about the potential changes to the python front end
instances. Currently an instance could use at least 200mb. Soft
memory limit errors aside you could bump into the hard limit
(MemoryError) at 300mb. I don't think it is wise to change that limit
down to 128mb. It really guts the capability of task queues if you
reduce the memory further. 10 minutes of processing time doesn't mean
much if you are that restricted by ram. Reducing memory on front end
instances will break some of our heavy weight features.

-Mike Wesner

Sergey Schetinin

unread,
May 18, 2011, 4:06:45 PM5/18/11
to google-a...@googlegroups.com
A couple more questions for the FAQ:

1) What are the expected limits on the concurrency for Python 2.7
instances? Assuming the requests handlers / threads are just waiting
for RPC to finish (say on urlfetch service), how many per-process are
allowed? This is probably still TBD, but a ballpark figure would be
very welcome.

2) How the keys-only queries will be charged for?

3) What controls are in place to make sure that the instances do not
get stuck on a bad / slow host? I have experienced very different
response times from a noop WSGI app hosted on GAE, and given the costs
will now be tied very directly to the latency, how can you make us
comfortable with the fact that this latency is volatile and often
completely out of our control? (or remove the volatility)

4) Can we have some assurance that the hosts are not oversold and the
CPU / Memory quota is actually guaranteed? Volatility in response
times (as measured by the GAE dashboard itself) suggests that
different hosts are under a different load and sometimes the
instance's process has to wait to get to run on a CPU. (When a no-op
app sometimes runs in 10ms and sometimes in 300ms+, that doesn't look
like guaranteed CPU to me).

5) Can we configure scheduler to shut instances down faster than in 15
minutes? (And not get charged for that idle time). If not, please
justify this limitation.

6) Will we have a way to explicitly shut down an instance from the
instance itself? (Without returning an error, basically to suggest to
scheduler that "this is the last request I want to handle")

7) Will the pricing become stable after this change? How can you
assure us that it will?

8) Is there any intention to adjust the prices in a year or two to
account for falling hardware prices?

Thank you.

-Sergey

PS I also wanted to mention to people asking if GIL will be removed --
of course it will stay. Also, there's no need to remove it, so please
don't make random requests and learn what GIL is and why it's there. I
would bet that the concurrency will be via regular Python threads (no
multiprocessing), but the app itself would not be allowed to spawn or
control those threads.

--
http://self.maluke.com/

vlad

unread,
May 18, 2011, 4:23:47 PM5/18/11
to google-a...@googlegroups.com
Many hosting providers advertise unlimited bandwidth. I heard that once/if you really start taking advantage of that they suspend your account. Essentially they count on vast majority of their accounts never needing much bandwidth but the Unlimited offer looks so enticing.

Chris Farmiloe

unread,
May 18, 2011, 4:26:41 PM5/18/11
to google-a...@googlegroups.com
Mike, 

I believe the temporary half-sized Python instances will be optional. If they don't suit your application, you won't have to choose them.

Brandon Wirtz

unread,
May 18, 2011, 4:27:41 PM5/18/11
to google-a...@googlegroups.com

It was a joke… My Sprint Phone has Unlimited Text, Talk and Data.  It would be farer to say unmetered… Obviously I can’t download 100 Terabytes of data a month the phone won’t go that fast, nor can I talk 2000 hours a month, because I can only have one conversation at a time.

 

-Brandon

--

goog_fanboy

unread,
May 18, 2011, 5:58:32 AM5/18/11
to Google App Engine
AppEngine team, I know you are brilliant programmers, and many don't
care much for the business side of things. But, can we get at least
some of your thoughts about the new PRICING and the change.

For me, as someone who have been evangelizing AppEngine in person and
in forums, it's like a slap in the face. I do realize that you must
make money from this endeavor, but can we hear you say in this. A post
in the blog dedicated to just this issue would be appreciated.

Like someone here in the group said, i looks like a move from pure
PaaS towards IaaS, which BTW is just the opposite of the Windows Azure
team, which slowly move from IaaS towards PaaS.

I looks like the (major) change in pricing goes very much against you
motto (don't be evil). Even if you miscalculated pricing when you
started AppEngine (maybe you set your pricing too low then), or you
didn't expect the king of users you get (maybe too many spammers or
malicious users), we want your say.

Luís Marques

unread,
May 18, 2011, 6:04:18 PM5/18/11
to Google App Engine
One problem people seem to have with the new pricing is the sudden
transition between 0$ and 9$.
The change to "max(9$, used billable quota)" from the earlier "$9 +
used billable quota" is nice, but still makes the gap somewhat
jarring.
I was thinking, can't there be a middle ground between:

1) small fixed quotas, min $0, max 0$
2) very large fixed quotas, min 9$, max unlimited$

What is the rationale for the $9? To recoup the losses from the $0
loss leader? To support the cost of the free quota that paid apps
receive (e.g. 24 free IHs)? To provide guarantees for serious apps?
(how so?).

Consider offering a billing class which doesn't need to be
particularly generous regarding fixed quotas, but is more elastic than
"max $0 billable quota". That would allow for, say, a web service
which has very low traffic but needs 600 MB of HR storage.

BTW: looking at the price of reserved front-end instances, if one had
to allocate all of the provided free front-end instances, that would
cost 0.05$ * 24h * 30d = 36$ per month. So the 9$ now seems cheap. But
why bundle all that and charge the 9$? You are offering 720 free
monthly instance hours. Many people won't be needing that, just the
elasticity that comes with billing. So just let people buy a whatever
amount they need. Some will need less, and will pay less. Others will
buy more and pay proportionally.

nickmilon

unread,
May 18, 2011, 6:42:15 PM5/18/11
to Google App Engine
@Sergey good questions.
IMHO this is a sisyphean task, new policy has opened Pandora's box
with questions popping up from it in a much faster rate that can be
answered.
Nick

Jeff Schnitzer

unread,
May 18, 2011, 6:48:03 PM5/18/11
to google-a...@googlegroups.com
The abrupt transition from $0 to $9 does seem a bit odd... is this
just to work around the deficiencies in Google Checkout that produce
the current $0.01 bills?

Jeff

2011/5/18 Luís Marques <luism...@gmail.com>:

rekby

unread,
May 18, 2011, 6:52:25 PM5/18/11
to Google App Engine
It isn't bad only for write operations. Get operations have same CPU
time in both storage type. http://code.google.com/intl/en/appengine/docs/java/datastore/hr/

On May 18, 7:47 pm, "Gregory D'alesandre" <gr...@google.com> wrote:
> > > A: We are...
>
> read more »

Brandon Wirtz

unread,
<