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 On Fri, Jun 24, 2011 at 12:36 PM, JH <[email protected]> wrote: > 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" <[email protected]> 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 > > 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 > > 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? > > 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< > 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. 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< > http://code.google.com/appengine/docs/java/config/appconfig.html#Usin...>; > > 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<http://code.google.com/appengine/docs/python/tools/libraries.html> > > . > > - 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? > > 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. > > APIsQ: 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<http://www.google.com/enterprise/appengine/appengine_pricing.html > >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 APIsQ: 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. > > StorageQ: 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 TypesQ: 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 LimitsQ: 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. > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
