Updated App Engine Pricing FAQ!
4,236 views
Skip to first unread message
Gregory D'alesandre
Jun 24, 2011, 2:49:16 AM6/24/11
to Google App Engine group
Hello All!, Well, it took longer than expected, but here is the updated FAQ! I highlighted the new sections, it covers how always-on will work, full explanation of datastore API prices, description of the new scheduler knobs, and description of what is needed to prepare for Python 2.7 and concurrent requests. I hope this helps clarify some of the bigger questions people had and as always please let me know if you have additional questions. Thanks!
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.
Pending Request Queue: Where new requests wait when there are no instances available to serve the request
Pending Latency: The amount of time a request has been waiting in the Request Queue
Scheduler: Part of the App Engine infrastructure that determines which Instance should serve a request including whether or not a new Instance is needed.
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 Predicted Pending Latency). If the Predicted Pending Latency looks too long, a new instance may be 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 the current number of running Instances as an upper bound on how many Instances you will be charged for.
Q: How can I control the number of instances running?
A: The Scheduler determines how many instances should run for your application. 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 can be found below under “What adjustments will be available for the new scheduler?”
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. See “What code changes will I need to make in order to use Python 2.7?” below for more information.
Q: How many requests can an average instance handle?
A: 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 backend instance (approx 2.4GHz): 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 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: 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.
Q: What adjustments will be available for the new scheduler?
A: There will be 4 “knobs” provided in the new scheduler which will allow for adjustment of performance vs. cost:
- Min Idle Instances: This determines how many idle instances will be left running all the time in order to ensure instances are ready to go when there is a need based on the traffic. NOTE: This option is only available to Paid Apps and Apps for Premier Accounts.
- Max Idle Instances: This determines the maximum number of idle instances the scheduler will leave running to be ready for traffic. Lowering this value can save money, but if traffic is spikey it could mean repeated start-up times and costs
- Min Pending Latency: This is the minimum time that a request will wait in the Request Queue before the Scheduler will start a new instance. Requests waiting less than this long will not cause a new instance to be spun up.
- Max Pending Latency: This determines the longest time a request can wait in the Request Queue without having an instance which can serve it. If any requests have waited this long, an Instance will immediately be spun up to serve it.
Q: How will the scheduler knobs affect billing and my costs?
A: The individual knobs will affect your application as follows:
- Min Idle Instances: Increasing this will increase your bill by keeping a certain minimum number of idle Instances always running.
- Max Idle Instances: Decreasing this will likely decrease your bill as fewer idle instances will typically be running and we will not charge for any excessive idle Instances. In this case the scheduler knob is a suggestion to the scheduler but we will not charge you for excess if the scheduler ignores the suggestion. For instance, if you set Max Idle Instances to be 5 and the scheduler leaves 16 Instances up for some length of time, you will only be charged for 5 Instances.
- Min Pending Latency: Decreasing this will likely increase your bill as the Scheduler will spin up Instances to handle traffic more aggressively.
- Max Pending Latency: Increasing this will likely decrease your bill as the Scheduler will try to use the running instances more often before spinning up new ones.
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 in addition to a 15 minute startup fee, the startup fee covers what it takes for App Engine to bring up and down the instance. 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. Additionally, if the instance stops and then starts again within a 15 minute window, the startup fee will only be charged once and the instance will be considered “up” for the time that passed. For example, if an on-demand instance is serving traffic for 5 min, is then down for 4 minutes and then serving traffic for 3 more minutes, you will pay for (5+4+3)+15 minutes, or $0.08 / 60 * 27 = 3.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 for now.
Q: Do Frontend instances handle Task Queues and Cron?
A: Yes, the handle Task Queue Requests by default.
Q: Can reserved instance-hours be used the following week?
A: Unfortunately, no. If you pre-commit to a set of reserved instance-hours for a week you will be charged for those instance-hours regardless of whether they are used during that week.
Q: Can the experimental Go Runtime handle concurrent requests?
A: Not currently but we are actively working on it, stay tuned...
Q: What code changes will I need to make in order to use Python 2.7?
A: In general much of your current Python 2.5 code will run with Python 2.7 but there are some important changes that you might need to make:
- Start using django 1.2: The current Python runtime uses Django 0.96 by default (and you use Django implicitly when you use the templates built into the webapp framework). Because Python 2.7 will be a new runtime we do not plan to package or support this obsolete version. We will package and support django 1.2 at a minimum. In order to prepare for this, the best thing to do is ensure your code will run under django 1.2, instructions on how to use Django 1.2 can be found here.
- Python 2.7 Support: I know this seems like it goes without saying but we’ll say it anyway, your code need to run under Python 2.7 in order to be used with the new runtime.
Q: How will concurrent requests work with Python 2.7?
A: Python 2.7 will be a new runtime for App Engine. Concurrent requests will work in threads similar to the way today’s Java runtime supports concurrent requests with threads.
- Use a WSGI-compliant framework: In order to take advantage of running concurrent requests you won’t be able to use CGI, rather you’ll need to use a WSGI-compliant framework (this includes the webapp framework packaged with App Engine).
- Threadsafe: Because we are using threads to handle concurrent requests under Python 2.7, in order to take advantage of using concurrent requests your code must be threadsafe.
- All changes needed to make your code work Python 2.7 as listed in the previous question.
A: Based on the feedback we’ve received we are changing this $9 fee to be a minimum spend rather than a fee as 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: Is there free quota for Backends?
A: Yes, each App gets $0.72/day of backends usage for free.
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.
Q: Is there any intention to adjust the prices in a year or two to account for falling hardware prices?
A: We have no plans to change it (in either direction) in the future.
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 today it is 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 will show Stanzas rather than CPU hours.
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 Frontend 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: Could emails sent to admins be cheaper or free?
A: That’s a possibility that we can look into, if you think this is important, please star this issue: http://code.google.com/p/googleappengine/issues/detail?id=5235.
A: There are 3 categories of Datastore operations:
- Write operations (Entity Put, Entity Delete, Index Write), each of these operations will cost $0.10 per 100k operations
- Read operations (Query, Entity Fetch), each of these operations will cost $0.07 per 100k operations
- Small operations (Key Fetch, Id Allocation), each of these operations will cost $0.01 per 100k operations
Q: Does the size of entity fetched make any difference?
A: No
Q: Under the new model for the Datastore API calls, does it mean that I don't care 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])?
A: Performing operations in batches does not affect the cost. Although it is still more efficient as it requires fewer round-trips to our backends which will decrease latency.
Q: If I do db.get([key1, key2]), and two entities were fetched, how many 'operations' have I consumed?
A: 2 entity fetches
Q: If key2 didn't exist and only one entity was fetched, what would be the charges?
A: 2 entity fetches
Q: If db.get(key1) fetches a 5kb entity and db.get(key2) fetches a 500kb entity, what's the difference in charges?
A: No difference
Q: Under the new scheme, is it more economical to do a keys-only query that fetches 1000 keys, and then do a get on the 500 of them that I need, or just do a regular (non keys-only) query for all 1000 directly?
A: The first is more economical. Fetching 1000 keys + fetching 500 entities = $0.0001 + 0.00035 = $0.00045; fetching 1000 entities = $0.0007.
A: No, only a limited amount of logs are currently stored per app and they are not counted against storage quota.
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, all 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.
A: Yes, we can grandfather in HRD apps that are migrating from old apps.
Greg D'Alesandre
Senior Product Manager, Google App Engine
------
Post-Preview Pricing FAQ
When Google App Engine leaves Preview in the second half of 2011, the pricing will change. Details are listed here: http://www.google.com/enterprise/appengine/appengine_pricing.html. This FAQ is intended to help answer some of the frequently asked questions about the new model.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.
Pending Request Queue: Where new requests wait when there are no instances available to serve the request
Pending Latency: The amount of time a request has been waiting in the Request Queue
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 Predicted Pending Latency). If the Predicted Pending Latency looks too long, a new instance may be 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 the current number of running Instances as an upper bound on how many Instances you will be charged for.
Q: How can I control the number of instances running?
A: The Scheduler determines how many instances should run for your application. 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 can be found below under “What adjustments will be available for the new scheduler?”
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. See “What code changes will I need to make in order to use Python 2.7?” below for more information.
Q: How many requests can an average instance handle?
A: 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 backend instance (approx 2.4GHz): 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 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: 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.
Q: What adjustments will be available for the new scheduler?
A: There will be 4 “knobs” provided in the new scheduler which will allow for adjustment of performance vs. cost:
- Min Idle Instances: This determines how many idle instances will be left running all the time in order to ensure instances are ready to go when there is a need based on the traffic. NOTE: This option is only available to Paid Apps and Apps for Premier Accounts.
- Max Idle Instances: This determines the maximum number of idle instances the scheduler will leave running to be ready for traffic. Lowering this value can save money, but if traffic is spikey it could mean repeated start-up times and costs
- Min Pending Latency: This is the minimum time that a request will wait in the Request Queue before the Scheduler will start a new instance. Requests waiting less than this long will not cause a new instance to be spun up.
- Max Pending Latency: This determines the longest time a request can wait in the Request Queue without having an instance which can serve it. If any requests have waited this long, an Instance will immediately be spun up to serve it.
Q: How will the scheduler knobs affect billing and my costs?
A: The individual knobs will affect your application as follows:
- Min Idle Instances: Increasing this will increase your bill by keeping a certain minimum number of idle Instances always running.
- Max Idle Instances: Decreasing this will likely decrease your bill as fewer idle instances will typically be running and we will not charge for any excessive idle Instances. In this case the scheduler knob is a suggestion to the scheduler but we will not charge you for excess if the scheduler ignores the suggestion. For instance, if you set Max Idle Instances to be 5 and the scheduler leaves 16 Instances up for some length of time, you will only be charged for 5 Instances.
- Min Pending Latency: Decreasing this will likely increase your bill as the Scheduler will spin up Instances to handle traffic more aggressively.
- Max Pending Latency: Increasing this will likely decrease your bill as the Scheduler will try to use the running instances more often before spinning up new ones.
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 in addition to a 15 minute startup fee, the startup fee covers what it takes for App Engine to bring up and down the instance. 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. Additionally, if the instance stops and then starts again within a 15 minute window, the startup fee will only be charged once and the instance will be considered “up” for the time that passed. For example, if an on-demand instance is serving traffic for 5 min, is then down for 4 minutes and then serving traffic for 3 more minutes, you will pay for (5+4+3)+15 minutes, or $0.08 / 60 * 27 = 3.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 for now.
Q: Do Frontend instances handle Task Queues and Cron?
A: Yes, the handle Task Queue Requests by default.
Q: Can reserved instance-hours be used the following week?
A: Unfortunately, no. If you pre-commit to a set of reserved instance-hours for a week you will be charged for those instance-hours regardless of whether they are used during that week.
Q: Can the experimental Go Runtime handle concurrent requests?
A: Not currently but we are actively working on it, stay tuned...
Q: What code changes will I need to make in order to use Python 2.7?
A: In general much of your current Python 2.5 code will run with Python 2.7 but there are some important changes that you might need to make:
- Start using django 1.2: The current Python runtime uses Django 0.96 by default (and you use Django implicitly when you use the templates built into the webapp framework). Because Python 2.7 will be a new runtime we do not plan to package or support this obsolete version. We will package and support django 1.2 at a minimum. In order to prepare for this, the best thing to do is ensure your code will run under django 1.2, instructions on how to use Django 1.2 can be found here.
- Python 2.7 Support: I know this seems like it goes without saying but we’ll say it anyway, your code need to run under Python 2.7 in order to be used with the new runtime.
Q: How will concurrent requests work with Python 2.7?
A: Python 2.7 will be a new runtime for App Engine. Concurrent requests will work in threads similar to the way today’s Java runtime supports concurrent requests with threads.
- Use a WSGI-compliant framework: In order to take advantage of running concurrent requests you won’t be able to use CGI, rather you’ll need to use a WSGI-compliant framework (this includes the webapp framework packaged with App Engine).
- Threadsafe: Because we are using threads to handle concurrent requests under Python 2.7, in order to take advantage of using concurrent requests your code must be threadsafe.
- All changes needed to make your code work Python 2.7 as listed in the previous question.
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 as 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: Is there free quota for Backends?
A: Yes, each App gets $0.72/day of backends usage for free.
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.
Q: Is there any intention to adjust the prices in a year or two to account for falling hardware prices?
A: We have no plans to change it (in either direction) in the future.
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 today it is 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 will show Stanzas rather than CPU hours.
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 Frontend 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: Could emails sent to admins be cheaper or free?
A: That’s a possibility that we can look into, if you think this is important, please star this issue: http://code.google.com/p/googleappengine/issues/detail?id=5235.
Datastore APIs
Q: Which operations are being charged for?A: There are 3 categories of Datastore operations:
- Write operations (Entity Put, Entity Delete, Index Write), each of these operations will cost $0.10 per 100k operations
- Read operations (Query, Entity Fetch), each of these operations will cost $0.07 per 100k operations
- Small operations (Key Fetch, Id Allocation), each of these operations will cost $0.01 per 100k operations
Q: Does the size of entity fetched make any difference?
A: No
Q: Under the new model for the Datastore API calls, does it mean that I don't care 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])?
A: Performing operations in batches does not affect the cost. Although it is still more efficient as it requires fewer round-trips to our backends which will decrease latency.
Q: If I do db.get([key1, key2]), and two entities were fetched, how many 'operations' have I consumed?
A: 2 entity fetches
Q: If key2 didn't exist and only one entity was fetched, what would be the charges?
A: 2 entity fetches
Q: If db.get(key1) fetches a 5kb entity and db.get(key2) fetches a 500kb entity, what's the difference in charges?
A: No difference
Q: Under the new scheme, is it more economical to do a keys-only query that fetches 1000 keys, and then do a get on the 500 of them that I need, or just do a regular (non keys-only) query for all 1000 directly?
A: The first is more economical. Fetching 1000 keys + fetching 500 entities = $0.0001 + 0.00035 = $0.00045; fetching 1000 entities = $0.0007.
Storage
Q: Are logs counted as part of “Storage Quota”A: No, only a limited amount of logs are currently stored per app and they are not counted against storage quota.
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, all 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 HRD apps that are migrating from old apps.
Vinuth Madinur
Jun 24, 2011, 3:47:16 AM6/24/11
to google-a...@googlegroups.com
Disappointed that developers have to start tinkering with the underlying scheduler.
And the 15-minute "startup" fee is worse than the earlier 15 minute "minimum" granularity. If your traffic is bursty(an instance is required for less than 15minutes), you always pay more than twice the amount of resources you used.
"Usage Based Pricing"?
And no intermediate plan without an SLA.
Disappointed.
Just to clarify: does "half-instance" for Python mean 48 half-instance hours under the free quota?
~Vinuth.
--
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.
JH
Jun 24, 2011, 8:36:12 AM6/24/11
to Google App Engine
Greg,
Glad to see an update to this FAQ. Unfortunately it sounds like I am
loosing the "Always ON" feature I like so much.
That being said, to work with this new model I would LOVE to see the
scheduler have a schedule.
For instance, my apps are primarily used by the corporate world. So
I'd like to have more aggressive instances mon-fri 8-5. At night and
on the weekends I don't care if I have even 1 idle instance since my
apps are rarely used then. The rare user could wait a couple seconds
for an instance to spin up. I know this probably won't be a priority
but I'd just like to put it out there in case anyone is listening.
That would really help me to work with this "new" model. Possibly you
could define multiple scheduler setting profiles and use a cron job to
change from 1 to another? I'm sure you guys can come up with a really
elegant solution.
Thanks,
On Jun 24, 1:49 am, "Gregory D'alesandre" <gr...@google.com> wrote:
> Hello All!, Well, it took longer than expected, but here is the updated FAQ!
> I highlighted the new sections, it covers how always-on will work, full
> explanation of datastore API prices, description of the new scheduler knobs,
> and description of what is needed to prepare for Python 2.7 and concurrent
> requests. I hope this helps clarify some of the bigger questions people had
> and as always please let me know if you have additional questions. Thanks!
>
> Greg D'Alesandre
> Senior Product Manager, Google App Engine
>
> ------
> Post-Preview Pricing FAQWhen Google App Engine leaves Preview in the second
> requests<http://code.google.com/appengine/docs/java/config/appconfig.html#Usin...>,
> Java<http://code.google.com/appengine/docs/java/config/appconfig.html#Usin...>;
> here<http://code.google.com/appengine/docs/python/tools/libraries.html>
> .
> APIsQ: How were the APIs priced?
> StorageQ: Are logs counted as part of “Storage Quota”
Glad to see an update to this FAQ. Unfortunately it sounds like I am
loosing the "Always ON" feature I like so much.
That being said, to work with this new model I would LOVE to see the
scheduler have a schedule.
For instance, my apps are primarily used by the corporate world. So
I'd like to have more aggressive instances mon-fri 8-5. At night and
on the weekends I don't care if I have even 1 idle instance since my
apps are rarely used then. The rare user could wait a couple seconds
for an instance to spin up. I know this probably won't be a priority
but I'd just like to put it out there in case anyone is listening.
That would really help me to work with this "new" model. Possibly you
could define multiple scheduler setting profiles and use a cron job to
change from 1 to another? I'm sure you guys can come up with a really
elegant solution.
Thanks,
On Jun 24, 1:49 am, "Gregory D'alesandre" <gr...@google.com> wrote:
> Hello All!, Well, it took longer than expected, but here is the updated FAQ!
> I highlighted the new sections, it covers how always-on will work, full
> explanation of datastore API prices, description of the new scheduler knobs,
> and description of what is needed to prepare for Python 2.7 and concurrent
> requests. I hope this helps clarify some of the bigger questions people had
> and as always please let me know if you have additional questions. Thanks!
>
> Greg D'Alesandre
> Senior Product Manager, Google App Engine
>
> ------
> half of 2011, the pricing will change. Details are listed here:http://www.google.com/enterprise/appengine/appengine_pricing.html. This FAQ
> is intended to help answer some of the frequently asked questions about the
> new model.
> DefinitionsInstance: A small virtual environment to run your code with a
> is intended to help answer some of the frequently asked questions about the
> new model.
> 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.
> Pending Request Queue: Where new requests wait when there are no instances
> available to serve the request
> Pending Latency: The amount of time a request has been waiting in the
> Request Queue
> 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 InfrastructureQ: What’s an Instance?
> 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.
> Pending Request Queue: Where new requests wait when there are no instances
> available to serve the request
> Pending Latency: The amount of time a request has been waiting in the
> Request Queue
> Scheduler: Part of the App Engine infrastructure that determines which
> Instance should serve a request including whether or not a new Instance is
> needed.
> .
> - Python 2.7 Support: I know this seems like it goes without saying but
> we’ll say it anyway, your code need to run under Python 2.7 in order to be
> used with the new runtime.
>
> Q: How will concurrent requests work with Python 2.7?
> A: Python 2.7 will be a new runtime for App Engine. Concurrent requests
> will work in threads similar to the way today’s Java runtime supports
> concurrent requests with threads.
> - Use a WSGI-compliant framework: In order to take advantage of running
> concurrent requests you won’t be able to use CGI, rather you’ll need to use
> a WSGI-compliant framework (this includes the webapp framework packaged with
> App Engine).
> - Threadsafe: Because we are using threads to handle concurrent requests
> under Python 2.7, in order to take advantage of using concurrent requests
> your code must be threadsafe.
> - All changes needed to make your code work Python 2.7 as listed in the
> previous question.
> CostsQ: Is the $9/app/month a fee or a minimum spend?
> we’ll say it anyway, your code need to run under Python 2.7 in order to be
> used with the new runtime.
>
> Q: How will concurrent requests work with Python 2.7?
> A: Python 2.7 will be a new runtime for App Engine. Concurrent requests
> will work in threads similar to the way today’s Java runtime supports
> concurrent requests with threads.
> - Use a WSGI-compliant framework: In order to take advantage of running
> concurrent requests you won’t be able to use CGI, rather you’ll need to use
> a WSGI-compliant framework (this includes the webapp framework packaged with
> App Engine).
> - Threadsafe: Because we are using threads to handle concurrent requests
> under Python 2.7, in order to take advantage of using concurrent requests
> your code must be threadsafe.
> - All changes needed to make your code work Python 2.7 as listed in the
> previous question.
> 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 today it is 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<http://www.google.com/enterprise/appengine/appengine_pricing.html>that
> 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 today it is 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
> 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 will show
> Stanzas rather than CPU hours.
>
> 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 Frontend 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: Could emails sent to admins be cheaper or free?
> A: That’s a possibility that we can look into, if you think this is
> important, please star this issue:http://code.google.com/p/googleappengine/issues/detail?id=5235.
> Datastore APIsQ: Which operations are being charged for?
> 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 will show
> Stanzas rather than CPU hours.
>
> 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 Frontend 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: Could emails sent to admins be cheaper or free?
> A: That’s a possibility that we can look into, if you think this is
> important, please star this issue:http://code.google.com/p/googleappengine/issues/detail?id=5235.
> A: No, only a limited amount of logs are currently stored per app and they
> are not counted against storage quota.
> Usage TypesQ: What does the Premier cost of "$500/account" mean? Per Google
> are not counted against storage quota.
> 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, all
> 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 LimitsQ: If I migrate to HR Datastore, does that mean I have a "newly
> 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, all
> 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.
Barry Hunter
Jun 24, 2011, 10:12:04 AM6/24/11
to google-a...@googlegroups.com
On Fri, Jun 24, 2011 at 8:47 AM, Vinuth Madinur
<vinuth....@gmail.com> wrote:
> Disappointed that developers have to start tinkering with the underlying
> scheduler.
> And the 15-minute "startup" fee is worse than the earlier 15 minute
> "minimum" granularity. If your traffic is bursty(an instance is required for
> less than 15minutes), you always pay more than twice the amount of resources
> you used.
<vinuth....@gmail.com> wrote:
> Disappointed that developers have to start tinkering with the underlying
> scheduler.
> And the 15-minute "startup" fee is worse than the earlier 15 minute
> "minimum" granularity. If your traffic is bursty(an instance is required for
> less than 15minutes), you always pay more than twice the amount of resources
> you used.
Has that actually changed? Its the same thing, just stated in a
slightly different way.
You are not always changed the 15 minutes 'fee'. In the example in the
FAQ, only changed 4 minutes for the intermediate gap, not a full 15
minutes.
Strom
Jun 24, 2011, 10:48:52 AM6/24/11
to Google App Engine
This new 15 minute description is making it more difficult to
understand, but it seems to be the same system as previously.
An instance will die if there is no traffic for 15 minutes. You are
charged for these idle 15 minutes. It's that simple.
On Jun 24, 5:12 pm, Barry Hunter <barrybhun...@gmail.com> wrote:
> On Fri, Jun 24, 2011 at 8:47 AM, Vinuth Madinur
>
> >> - Min Pending Latency: This is the...
>
> read more »
understand, but it seems to be the same system as previously.
An instance will die if there is no traffic for 15 minutes. You are
charged for these idle 15 minutes. It's that simple.
On Jun 24, 5:12 pm, Barry Hunter <barrybhun...@gmail.com> wrote:
> On Fri, Jun 24, 2011 at 8:47 AM, Vinuth Madinur
>
>
> read more »
Ugorji Nwoke
Jun 24, 2011, 11:18:25 AM6/24/11
to google-a...@googlegroups.com
It seems slightly different. Now, you are charged for 15 minutes, even if your instance was shut off most of that time. It's no longer extra idle time tagged on waiting for requests, but now a mandatory fee tagged on even if the scheduler shut you off after being idle for 2 minutes.
See example where you are active for 5 minutes, then get shut down, then back up after 4 minutes, then active for 3 minutes, then get shut down. You are charged for the 5 minutes active + 4 minutes shutdown + 3 minutes active + 15 minutes instance-startup fee = 27 minutes.
Personally, I don't like it, as it feels more confusing - but I don't make the policy. I would have preferred a flat "we charge in increments of 15 minutes". ie once an instance is started, it will only be shutdown after multiples of 15 minutes, and charged for that live time (whether actively handling requests or not).
rekby
Jun 24, 2011, 11:25:10 AM6/24/11
to google-a...@googlegroups.com
Russian translate (русский перевод): http://timofey.koolin.ru/2011/06/faq-google-app-engine-24-2011.html
Strom
Jun 24, 2011, 11:57:32 AM6/24/11
to Google App Engine
On Jun 24, 6:18 pm, Ugorji <ugo...@gmail.com> wrote:
> Personally, I don't like it, as it feels more confusing - but I don't make
> the policy. I would have preferred a flat "we charge in increments of 15
> minutes". ie once an instance is started, it will only be shutdown after
> multiples of 15 minutes, and charged for that live time (whether actively
> handling requests or not).
I don't think it was ever charged by multiples of 15 minutes. I'm
> Personally, I don't like it, as it feels more confusing - but I don't make
> the policy. I would have preferred a flat "we charge in increments of 15
> minutes". ie once an instance is started, it will only be shutdown after
> multiples of 15 minutes, and charged for that live time (whether actively
> handling requests or not).
pretty sure it was always explained as having the instance stay idle
for 15 minutes after the last request.
However you are correct in that the new wording allows them to charge
for 15 minutes of idle time while allowing the scheduler to kill it
off whenever.
Tapir
Jun 24, 2011, 1:18:27 PM6/24/11
to Google App Engine
Now, gea has few advantages comparing other cloud services.
Before the price is the biggest advantage. Now it even becomes a
disadvantage.
IMHO, the price for instances is too high.
On Jun 24, 2:49 pm, "Gregory D'alesandre" <gr...@google.com> wrote:
> Hello All!, Well, it took longer than expected, but here is the updated FAQ!
> I highlighted the new sections, it covers how always-on will work, full
> explanation of datastore API prices, description of the new scheduler knobs,
> and description of what is needed to prepare for Python 2.7 and concurrent
> requests. I hope this helps clarify some of the bigger questions people had
> and as always please let me know if you have additional questions. Thanks!
>
> Greg D'Alesandre
> Senior Product Manager, Google App Engine
>
> ------
> Post-Preview Pricing FAQWhen Google App Engine leaves Preview in the second
> requests<http://code.google.com/appengine/docs/java/config/appconfig.html#Usin...>,
> Java<http://code.google.com/appengine/docs/java/config/appconfig.html#Usin...>;
> Scheduler will ...
>
> read more »
Before the price is the biggest advantage. Now it even becomes a
disadvantage.
IMHO, the price for instances is too high.
On Jun 24, 2:49 pm, "Gregory D'alesandre" <gr...@google.com> wrote:
> Hello All!, Well, it took longer than expected, but here is the updated FAQ!
> I highlighted the new sections, it covers how always-on will work, full
> explanation of datastore API prices, description of the new scheduler knobs,
> and description of what is needed to prepare for Python 2.7 and concurrent
> requests. I hope this helps clarify some of the bigger questions people had
> and as always please let me know if you have additional questions. Thanks!
>
> Greg D'Alesandre
> Senior Product Manager, Google App Engine
>
> ------
> half of 2011, the pricing will change. Details are listed here:http://www.google.com/enterprise/appengine/appengine_pricing.html. This FAQ
> is intended to help answer some of the frequently asked questions about the
> new model.
> DefinitionsInstance: A small virtual environment to run your code with a
> is intended to help answer some of the frequently asked questions about the
> new model.
> 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.
> Pending Request Queue: Where new requests wait when there are no instances
> available to serve the request
> Pending Latency: The amount of time a request has been waiting in the
> Request Queue
> 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 InfrastructureQ: What’s an Instance?
> 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.
> Pending Request Queue: Where new requests wait when there are no instances
> available to serve the request
> Pending Latency: The amount of time a request has been waiting in the
> Request Queue
> Scheduler: Part of the App Engine infrastructure that determines which
> Instance should serve a request including whether or not a new Instance is
> needed.
>
> read more »
Tapir
Jun 24, 2011, 1:22:33 PM6/24/11
to Google App Engine
How many instances will run simultaneously every CPU, averagely?
Anders
Jun 24, 2011, 3:41:57 PM6/24/11
to google-a...@googlegroups.com
Exactly. That's something service providers want to keep opaque so that they can cram in as many they can for maximum profit. Successful companies of the future have the motto: "Don't be opaque." ;-) Another trick they use is to set a fixed pricing model for many years to come, because the price/performance of computing power, data storage, communication etc doubles every year.
Joops
Jun 24, 2011, 5:20:58 PM6/24/11
to Google App Engine
Thanks very much for the update,
The change I am most nervous about is the datastore changes. Currently
I measure my (somewhat simplistic) performance goals by looking at the
CPU usage. (I quite regularly consider my cost per user by looking at
how much cpu usage I use in testing).
In order to prepare for the new model, I need to start thinking about
how many datastore operations I am doing.
So I was wondering, will you shortly be upgrading the backoffice so we
can see our data store stats for each of the types of operation.
Thanks very much
J.
At the moment, I am aware that I usually use 0.01-0.04 cpu hours on a
normal day, so for 10 cents I could support 25-100 users.
(I hope to drastically improve that)
I don't know how many datastore operations I am typically doing...
(although I will go and try to guess)
The change I am most nervous about is the datastore changes. Currently
I measure my (somewhat simplistic) performance goals by looking at the
CPU usage. (I quite regularly consider my cost per user by looking at
how much cpu usage I use in testing).
In order to prepare for the new model, I need to start thinking about
how many datastore operations I am doing.
So I was wondering, will you shortly be upgrading the backoffice so we
can see our data store stats for each of the types of operation.
Thanks very much
J.
At the moment, I am aware that I usually use 0.01-0.04 cpu hours on a
normal day, so for 10 cents I could support 25-100 users.
(I hope to drastically improve that)
I don't know how many datastore operations I am typically doing...
(although I will go and try to guess)
Gregory D'alesandre
Jun 24, 2011, 5:29:00 PM6/24/11
to google-a...@googlegroups.com
Now that you mention it, we just did :) If you look at the Admin Console, under "Quota Details", under "Datastore API" you should be able to see your usage of each of the 7 Ops mentioned. Let me know if you find it there and if it helps!
Greg
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
Gregory D'alesandre
Jun 24, 2011, 5:31:15 PM6/24/11
to google-a...@googlegroups.com
Interesting idea! Could you file an issue in our issue tracker (http://code.google.com/p/googleappengine/issues/list) so that folks can star it and we can get a sense for how many people might be interested?
Greg
Jeff Schnitzer
Jun 24, 2011, 7:04:41 PM6/24/11
to google-a...@googlegroups.com
Thanks, this clarifies much! Questions below:
On Thu, Jun 23, 2011 at 11:49 PM, Gregory D'alesandre <gr...@google.com> wrote:
Datastore APIs
Q: Which operations are being charged for?
A: There are 3 categories of Datastore operations:
- Write operations (Entity Put, Entity Delete, Index Write), each of these operations will cost $0.10 per 100k operations
- Read operations (Query, Entity Fetch), each of these operations will cost $0.07 per 100k operations
- Small operations (Key Fetch, Id Allocation), each of these operations will cost $0.01 per 100k operations
Q: Under the new scheme, is it more economical to do a keys-only query that fetches 1000 keys, and then do a get on the 500 of them that I need, or just do a regular (non keys-only) query for all 1000 directly?
A: The first is more economical. Fetching 1000 keys + fetching 500 entities = $0.0001 + 0.00035 = $0.00045; fetching 1000 entities = $0.0007.
This makes sense, and encourages more use of memcache. to hold entities. One question that I've been wondering a while - presuming no caching, does this query-keys+batch-get approach produce higher latency than a simple query, and if so, by how much?
Also, is there any way we can get the transaction timestamp out on datastore writes? This would *dramatically* improve the robustness of code that tries to keep memcache in sync with the datastore during contention. I've spoken with Alfred and Max about this, but I don't know if it's a priority. This could potentially reduce datastore bills by orders of magnitude.
Thanks,
Jeff
Waleed Abdulla
Jun 24, 2011, 7:55:47 PM6/24/11
to google-a...@googlegroups.com
Gregory, Thanks for the update.
I think the scheduler min & max pending latency should be per url (i.e. in app.yaml) rather than being global at the app level. Most apps have requests that require a quick response (UI and APIs), and others that don't (cron, some tasks, backend work, ..etc). I'd probably want to set my max pending latency to 50ms for UI requests and 5 seconds for some non-urgent tasks.
Waleed
--
Waleed Abdulla
Jun 24, 2011, 8:24:44 PM6/24/11
to google-a...@googlegroups.com
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).
How does that work? Can you share an example?
Also, instead of pushing the burden of supporting threading on to the developers, shouldn't GAE optimize resources behind the scenes? You're running many instances on every physical computer, so when one instance is idel, others should be using the CPU and other resources. If keeping an idle instance in memory costs too much, then adjust the pricing by adding a cost per idle second, or something along these lines.
My point is: GAE has a lot of limitations compared to other solutions, but it has one HUGE advantage: it's simple and scales automatically. That advantage is so big that it trumps all the other limitations (at least for me). Now that I have to manage my instances and rewrite my code to handle threading, I can't help but feel that I'm losing that one big advantage.
Waleed
Nickolas Daskalou
Jun 25, 2011, 12:40:08 AM6/25/11
to google-a...@googlegroups.com
Hi Greg,
Thanks for putting together the update. I have some questions, if you wouldn't mind answering them:
(1) Why no RAM-charge?
The argument that a CPU-charge was not reflective of an application's real resource usage is understandable, and that the underlying reason for changing the model was because RAM usage was not taken into account with the old model. Why not then just simply add a RAM-charge to account for this, instead of flipping the ecosystem on its head and drastically changing the pricing model, as you have now done? This question has been asked many times since the new pricing model was released and it is yet to receive an official answer.
As a side note, and with regards to each instance being pre-allocated a fixed amount of RAM upon creation: Wouldn't it be great if the geniuses at Google were able to come up with a way to utilise the non-used part of an instance's RAM for other things (eg. for extra global Memcache storage), and then when the instance requires more RAM, the system can just flush whatever is in the "non-used" part of that instance's RAM and hand it back to the instance? That would make for some serious resource-usage-optimisation!
(2) How do you propose we run MapReduce type jobs under the new pricing model?
The new (time used + 15 minutes) time charge for an instance would mean that running a MapReduce type job will come with a large cost overhead. For example, if such a job completes in 5 minutes and requires a number of new instances to be spun up and down (as the MapReduce philosophy dictates), 75% of the cost of this job would be in paying that extra 15 minute surcharge for each instance. So the cost of a 5 minute MapReduce job would be inflated by 4x. If we assume the new instance prices are inflated by 10x that of other offerings, a 5 minute MapReduce job will now cost 40x the amount if you were doing it elsewhere.
If the solution is to not run any MapReduce type jobs, then the past three years have been extremely poor education by Google, as we have been told time and time again that we should embrace and utilise the power of being able to run multiple instances in parallel to complete work that would have otherwise taken a much longer time to complete in serial. Furthermore, it is a great shame that the brilliant work done by Google Engineers such as Mike Aizatskyi and Brett Slatkin in creating design patterns and libraries that allow for massively-parallel work to be done is completely voided with the new prices.
(3) How can you justify your instance price when compared with Amazon EC2?
On the surface, when comparing the instance costs of GAE and AWS, it appears that GAE is quite competitive with their $0.08/hour vs AWS's default Standard Small $0.085/hour for on-demand instances. However, the RAM available for each instance type is dramatically different, GAE providing 128MB RAM vs AWS's 1.7GB RAM. Even AWS's $0.02/hour Micro instance trumps a GAE instance in terms of the available memory, where each AWS Micro instance is given 613MB RAM.
If the answer to this question is something along the lines of "our prices are a true reflection of the overhead required to run a PaaS offering", then see next question....
(4) Isn't gifting all apps $60/month a recipe for disaster?
If we assume that the new pricing model is a "fair" reflection of the costs associated with sustainably running GAE, then Google will be effectively gifting every single app $60/month under the new pricing model. With "the majority of current active apps" falling under the new free quotas, this means Google will be running at a huge loss of $700/year on most apps. Doesn't this go totally against the point of making GAE sustainable by introducing these new prices in the first place?
The only way I can see this making any sense is if the new pricing model is indeed a massively marked up price when compared to the real costs of running GAE, and $60/month is not even slightly close to what it is actually costing Google to support these free apps. From an economically viable point of view, I see no other way to justify the apparent $60/month "gift" to every app, other than the true cost is an extremely small fraction of that $60/month.
Greg, I'm sure most of us would appreciate a candid response to each of the above questions, and thanks in advance for your replies.
From a business point of view, Google should be very careful with their final decision on the new app pricing. Much of Google's current market value has come from the goodwill generated by their original "do no evil" motto. Most hugely successful companies who are not first to market today have one or two solid reasons why they have made it big, on top of their slightly improved technology offerings for which there was a big uptake of. For Apple it was their marketing, for Amazon their prices, and for Google it was their goodwill. Apart from the free quotas (which only really puts GAE in line with AWS), I see no goodwill being displayed here by Google.
Whilst GAE represents only a small portion of the Google business as a whole, it is a dangerous path Google is choosing to go down if they stick with their new prices, one which may see the good work done by others in the past to get Google to where it is today severely dented.
Cheers,
Nick
--
Gregory D'alesandre
Jun 25, 2011, 1:41:32 AM6/25/11
to google-a...@googlegroups.com
Hey Jeff, those are both good questions. The first I don't honestly know but I'll see if we can figure out an answer for it. The second seems reasonable, I'll chat with Alfred and Max about it.
Greg
--
Vinuth Madinur
Jun 25, 2011, 1:42:22 AM6/25/11
to google-a...@googlegroups.com
It's not the same.
When you say 15 minute minimum granularity, your usage of 5 minutes, 10 minutes, etc., is all absorbed into the 15-minute fixed fee. So if you use 5 minutes, you paid for 15m, for 10m you paid for 15m, for 15m you paid for 15m, for 20m you paid for 20m, etc.,
But now, your usage is charged extra. Plus if you are idle within the 15-minute duration, that is charged extra too.. doesn't make any sense at all. What is the rational behind "15-minute" startup fee? And why charge for idle time if the instance is used again within this duration?
If your instances are required to run for 15 minutes on an average, you are charged for 30 minutes. And this is the best case scenario if your average instance uptime is less than 15 minutes.
This is much worse than 15-minute minimum granularity.
Gregory D'alesandre
Jun 25, 2011, 2:27:59 AM6/25/11
to google-a...@googlegroups.com
Hi Nick, I've answered your questions below as best I can...
On Sat, Jun 25, 2011 at 4:40 AM, Nickolas Daskalou <ni...@daskalou.com> wrote:
Hi Greg,Thanks for putting together the update. I have some questions, if you wouldn't mind answering them:(1) Why no RAM-charge?The argument that a CPU-charge was not reflective of an application's real resource usage is understandable, and that the underlying reason for changing the model was because RAM usage was not taken into account with the old model. Why not then just simply add a RAM-charge to account for this, instead of flipping the ecosystem on its head and drastically changing the pricing model, as you have now done? This question has been asked many times since the new pricing model was released and it is yet to receive an official answer.
We have in essence added a RAM charge by charging for Instances. By having an Instance up with an allocated amount of memory you are essentially using that RAM. So, by charging for the Instance we are charging you for the combination of the RAM and CPU. We considered splitting this charge out so we would continue to charge CPU-hours and then also charge Instance-hours (which we could've called RAM-hours). This both seemed more confusing as well as would not have been cheaper, so it didn't seem worthwhile. I know that there has been a lot of discussion about charging this way instead. In the end it, whether you call it RAM-hours or Instance-hours and whether or not you charge for CPU-hours on top of it, it would end up with the same result. Which is that applications are charged for the amount of RAM allocated and the amount of time it is allocated for. This means applications that want to save money will need to optimize around using fewer RAM-hours which in essence means taking less time to get things done. But I might be misunderstanding the question because if you feel a RAM charge is straightforward I'm not sure I understand why you feel charging Instance-hours is "flipping the ecosystem on its head." I hope that helps give some clarity.
As a side note, and with regards to each instance being pre-allocated a fixed amount of RAM upon creation: Wouldn't it be great if the geniuses at Google were able to come up with a way to utilise the non-used part of an instance's RAM for other things (eg. for extra global Memcache storage), and then when the instance requires more RAM, the system can just flush whatever is in the "non-used" part of that instance's RAM and hand it back to the instance? That would make for some serious resource-usage-optimisation!(2) How do you propose we run MapReduce type jobs under the new pricing model?The new (time used + 15 minutes) time charge for an instance would mean that running a MapReduce type job will come with a large cost overhead. For example, if such a job completes in 5 minutes and requires a number of new instances to be spun up and down (as the MapReduce philosophy dictates), 75% of the cost of this job would be in paying that extra 15 minute surcharge for each instance. So the cost of a 5 minute MapReduce job would be inflated by 4x. If we assume the new instance prices are inflated by 10x that of other offerings, a 5 minute MapReduce job will now cost 40x the amount if you were doing it elsewhere.
We are working on optimizing the MapReduce scheduler to work within the constraints of the pricing model to make it cost effective. You've mentioned the price being 10x more than other offerings before, I was curious where you got that number from and which services you are benchmarking it against?
If the solution is to not run any MapReduce type jobs, then the past three years have been extremely poor education by Google, as we have been told time and time again that we should embrace and utilise the power of being able to run multiple instances in parallel to complete work that would have otherwise taken a much longer time to complete in serial. Furthermore, it is a great shame that the brilliant work done by Google Engineers such as Mike Aizatskyi and Brett Slatkin in creating design patterns and libraries that allow for massively-parallel work to be done is completely voided with the new prices.
I assume my previous answers covers this as well.
(3) How can you justify your instance price when compared with Amazon EC2?On the surface, when comparing the instance costs of GAE and AWS, it appears that GAE is quite competitive with their $0.08/hour vs AWS's default Standard Small $0.085/hour for on-demand instances. However, the RAM available for each instance type is dramatically different, GAE providing 128MB RAM vs AWS's 1.7GB RAM. Even AWS's $0.02/hour Micro instance trumps a GAE instance in terms of the available memory, where each AWS Micro instance is given 613MB RAM.
You are comparing very different services on the basis of RAM alone. RAM is one of many factors which dictate what you can accomplish with a service. App Engine also includes a slew of free APIs, no need to manage your App (the newly exposed Scheduler knobs are a convenience rather than a necessity), no need to run and maintain an OS (which typically consumes quite a bit of RAM), etc. App Engine is a Platform, when it comes down to it we've decided to use resources (both electronic and human) differently and so we are charging differently for it as well.
If the answer to this question is something along the lines of "our prices are a true reflection of the overhead required to run a PaaS offering", then see next question....(4) Isn't gifting all apps $60/month a recipe for disaster?If we assume that the new pricing model is a "fair" reflection of the costs associated with sustainably running GAE, then Google will be effectively gifting every single app $60/month under the new pricing model. With "the majority of current active apps" falling under the new free quotas, this means Google will be running at a huge loss of $700/year on most apps. Doesn't this go totally against the point of making GAE sustainable by introducing these new prices in the first place?The only way I can see this making any sense is if the new pricing model is indeed a massively marked up price when compared to the real costs of running GAE, and $60/month is not even slightly close to what it is actually costing Google to support these free apps. From an economically viable point of view, I see no other way to justify the apparent $60/month "gift" to every app, other than the true cost is an extremely small fraction of that $60/month.
We hope it isn't a recipe for disaster :) I think you assume that every App not going over the free quota uses all of their free quota which isn't accurate. The other reason it works is that we built this into our pricing model (the understanding that we are giving away a lot of resources). Another way to look at it is if we had no free quota at all, our per hour and per operation prices would be lower but you'd be paying for everything you used. We didn't feel that was a good solution because we believe it is really important that developers can use App Engine for free and not just for 30 days or even a year. We are also happy to have people running applications that they find useful under the free quotas.
Greg, I'm sure most of us would appreciate a candid response to each of the above questions, and thanks in advance for your replies.
I hope my answers helped and thanks for your thoughts below!
Greg
Vinuth Madinur
Jun 25, 2011, 2:43:27 AM6/25/11
to google-a...@googlegroups.com
On Sat, Jun 25, 2011 at 11:57 AM, Gregory D'alesandre <gr...@google.com> wrote:
Hi Nick, I've answered your questions below as best I can...On Sat, Jun 25, 2011 at 4:40 AM, Nickolas Daskalou <ni...@daskalou.com> wrote:
Hi Greg,Thanks for putting together the update. I have some questions, if you wouldn't mind answering them:(1) Why no RAM-charge?The argument that a CPU-charge was not reflective of an application's real resource usage is understandable, and that the underlying reason for changing the model was because RAM usage was not taken into account with the old model. Why not then just simply add a RAM-charge to account for this, instead of flipping the ecosystem on its head and drastically changing the pricing model, as you have now done? This question has been asked many times since the new pricing model was released and it is yet to receive an official answer.We have in essence added a RAM charge by charging for Instances. By having an Instance up with an allocated amount of memory you are essentially using that RAM. So, by charging for the Instance we are charging you for the combination of the RAM and CPU. We considered splitting this charge out so we would continue to charge CPU-hours and then also charge Instance-hours (which we could've called RAM-hours). This both seemed more confusing as well as would not have been cheaper, so it didn't seem worthwhile. I know that there has been a lot of discussion about charging this way instead. In the end it, whether you call it RAM-hours or Instance-hours and whether or not you charge for CPU-hours on top of it, it would end up with the same result. Which is that applications are charged for the amount of RAM allocated and the amount of time it is allocated for. This means applications that want to save money will need to optimize around using fewer RAM-hours which in essence means taking less time to get things done. But I might be misunderstanding the question because if you feel a RAM charge is straightforward I'm not sure I understand why you feel charging Instance-hours is "flipping the ecosystem on its head." I hope that helps give some clarity.
I guess the differences are as follows:
1. With instance hours the focus is not on optimizing RAM consumption at all, but on reducing latency (increasing RAM consumption, reducing costs) and controlling when instances come up and go.
2. With RAM-hours pricing, idle instances would cost lesser as CPU-hours are not charged.
3. The pricing would be linear and pay-for-what-you-use: amount of RAM for the time used. Not a fixed instance type with some amount of RAM.
So, it is "flipping the ecosystem on its head".
Gregory D'alesandre
Jun 25, 2011, 3:17:37 AM6/25/11
to google-a...@googlegroups.com
Interesting idea. Could you use backends for non-urgent tasks? Then the scheduler wouldn't need to be involved at all.
Greg
Gregory D'alesandre
Jun 25, 2011, 3:24:23 AM6/25/11
to google-a...@googlegroups.com
On Sat, Jun 25, 2011 at 12:24 AM, Waleed Abdulla <wal...@ninua.com> wrote:
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).How does that work? Can you share an example?Also, instead of pushing the burden of supporting threading on to the developers, shouldn't GAE optimize resources behind the scenes? You're running many instances on every physical computer, so when one instance is idel, others should be using the CPU and other resources. If keeping an idle instance in memory costs too much, then adjust the pricing by adding a cost per idle second, or something along these lines.
That is in essence what we've done, added a charge having an instance residing in memory, the difference is that we will not be billing the CPU separately anymore.
My point is: GAE has a lot of limitations compared to other solutions, but it has one HUGE advantage: it's simple and scales automatically. That advantage is so big that it trumps all the other limitations (at least for me). Now that I have to manage my instances and rewrite my code to handle threading, I can't help but feel that I'm losing that one big advantage.
Sorry that hear you feel that way Waleed. But maybe there is a misunderstanding, you don't have to manage instances at all (in fact the only options we give you allow you to tune how we manage your instances). It still scales automatically. In terms of rewriting code to handle threading, we suggest it because it means you can do more with less memory and it will save you money but if you'd rather not and are willing to pay for it, you don't have to.
Hope that helps!
Greg
Waleed Abdulla
Jun 25, 2011, 3:58:49 AM6/25/11
to google-a...@googlegroups.com
On Sat, Jun 25, 2011 at 12:17 AM, Gregory D'alesandre <gr...@google.com> wrote:
Interesting idea. Could you use backends for non-urgent tasks? Then the scheduler wouldn't need to be involved at all.
I could use resident backends, but then I have to adjust the number of instances up and down as load fluctuates throughout the day. And if I use dynamic backends, then the scheduler will get involved, right? Also, it's not only for backend work; there are cases where you need to adjust priority per API. For example, I have user facing APIs that should be really fast. And I have other APIs that I use to sync data between GAE and my other servers. Those don't have to be fast, so I'd rather keep the cost lower.
Robert Kluin
Jun 25, 2011, 4:04:16 AM6/25/11
to google-a...@googlegroups.com
This is an interesting idea. Would be great to have control per
app.yaml WSGI app defined!
app.yaml WSGI app defined!
Actually, even getting per-version config would be great. At least
then we could use a separate version for low-priority backend
processing.
Robert
Kngt
Jun 25, 2011, 9:07:34 AM6/25/11
to google-a...@googlegroups.com
All in all, I'm satisfied with the clarifications (TANSTAAFL being given).
Especially, +1 for making entity reads cheaper than writes and +1 for the cheap price for keys-only queries.
I can work with that. The one remaining issue, to my mind, is the lack of formalization for memcache (i.e., how much memory is allocated to the cache? what's the entity eviction policy? etc.)
Sylvain
Jun 25, 2011, 9:17:46 AM6/25/11