>From my FAQ: My current provider offers me Unlimited bandwidth for $14.95 a month. How much is your unlimited plan?
:-) -----Original Message----- From: google-appengine@googlegroups.com [mailto:google-appengine@googlegroups.com] On Behalf Of Sudhir Sent: Wednesday, May 18, 2011 12:24 AM To: Google App Engine Subject: [google-appengine] Re: FAQ for out of preview pricing changes Greg, Great job with the FAQ... I think it clarifies things a lot, and is quite will written. I'm still not clear on some points, though. If I do db.get([key1, key2]), and two entities were fetched, how many 'operations' have I consumed? If key2 didn't exist and only one entity was fetched, what would be the charges? If db.get(key1) fetches a 5kb entity and db.get(key2) fetches a 500kb entity, what's the difference in charges? Under the new scheme, is it more economical to do keys only query that fetches 1000 keys, and then do a get on the 500 of them that I need, or just fetch all 1000 directly? Being able to provide a definitive answer to these questions would really help. Sudhir On May 18, 11:54 am, Maxim Lacrima <lacrima.ma...@gmail.com> wrote: > Hi! > > Under the new model for the Datastore API calls, does it mean that I > don't care anymore about performing operations in batches? So in terms > of costs db.get(key1); db.get(key2) is essentially the same as db.get([key1, key2])? > > Thank you! > > On 18 May 2011 07:49, Gregory D'alesandre <gr...@google.com> wrote: > > > > > > > > > Hello All! > > > As you've likely heard, when Google App Engine leaves Preview in the > >second half of 2011, the pricing model will change. Prices are listed here: > >http://www.google.com/enterprise/appengine/appengine_pricing.html. > >But that leaves a lot of questions unanswered, this FAQ is intended > >to help answer some of the frequently asked questions about the new > >model. We are interested in hearing additional thoughts and > >comments you have based on this. Once it is relatively stable I'll > >add it to our official docs. If you find there is something you > >want to know but it is not yet answered, just ask and I'll try to > >answer it as clearly as possible. We've made some changes based on > >the feedback we've gotten (from this group in particular), they are > >bolded below but not updated on the external pages yet. There are > >still blanks to fill in and I will be sending that information to > >this group first in order as it is available. Finally, thank you > >for your questions and bearing with us as we are ironing out details, I and the whole App Engine team very much appreciate it. > > > Greg D'Alesandre > > Senior Product Manager, Google App Engine > > > ------------------- > > > *Definitions* > > *Instance*: A small virtual environment to run your code with a > > reserved amount of CPU and Memory. > > *Frontend Instance*: An Instance running your code and scaling > > dynamically based on the incoming requests but limited in how long a request can run. > > *Backend Instance*: An Instance running your code with limited > > scaling based on your settings and potentially starting and stopping > > based on your actions. > > *Scheduler*: Part of the App Engine infrastructure that determines > > which Instance should serve a request including whether or not a new > > Instance is needed. > > > *Serving Infrastructure* > > Q: What’s an Instance? > > A: When App Engine starts running your code it creates a small > > virtual environment to run your code with a reserved amount of CPU > > and Memory. For example if you are running a Java app, we will > > start a new JVM for you and load your code into it. > > > Q: Is an App Engine Instance similar to a VM from infrastructure providers? > > A: Yes and no, they both have a set amount of CPU and Memory > > allocated to them, but GAE instances don’t have the overhead of > > operating systems or other applications running, so a much larger > > percentage of the CPU and memory is considered “usable.” They also > > operate against high-level APIs and not down through layers of code > > to virtual device drivers, so it’s more efficient, and allows all the services to be fully managed. > > > Q: How does GAE determine the number of Frontend Instances to run? > > A: For each new request, the Scheduler decides whether there is an > > available Instance for the request, the request should wait, or a > > new Instance should be created to service the request. It looks at > > the number of Instances, the throughput of the Instances, and the > > number of requests waiting. Based on that it predicts how long it > > will take before it can serve the request (aka the Pending Latency). > > If it predicts the delay will be over 1 second, a new Instance is > > created. If it looks like an Instance is no longer needed, it will take that Instance down. > > > Q: Should I assume I will be charged for the number of Instances > > currently being shown in the Admin console? > > A: No, we are working to change the Scheduler to optimize the > > utilization of instances, so that number should go down somewhat. > > If you are using Java, you can also make your app threadsafe and > > take advantage of handling concurrent requests. You can look at > > that as an upper bound on how many Instances you will be charged for. > > > Q: How can I control the number of instances running? > > A: With the new Scheduler you’ll have the ability to choose a set of > > parameters that will help you specify how many instances are spun up > > to serve your traffic. More information about the specific > > parameters and how they will affect the Scheduler will be available on this within a few weeks. > > > Q: What can I control in terms of how many requests an Instance can handle? > > A: The single largest factor is your application’s latency in > > handling the request. If you service requests quickly, a single > > instance can handle a lot of requests. Also, Java apps support > > concurrent > > requests<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.* > > > Q: How many requests can an average instance handle? > > A: Single-threaded Instances (python or java) can currently handle 1 > > concurrent request. Single-threaded Instances (python or java) can > > currently handle 1 concurrent request. Therefore there is a direct > > relationship between the latency and number of requests which can be > > handled on the instance per second, for instance: 10ms latency = 100 > > request/second/Instance, 100ms latency = 10 request/second/Instance, etc. > > Multi-Threaded Instances can handle many concurrent requests. > > Therefore there is a direct relationship between the cpu consumed > > and the number of requests/second. For instance, for a B4 (approx > > 2.4GHz) instance: consuming > > 10 Mcycles/request = 240 request/second/Instance, 100 > > Mcycles/request = 24 request/second/Instance, etc. These numbers > > are the ideal case but they are pretty close to what you should be able to accomplish on an Instance. > > Multi-Threaded instances are currently only supported for Java; we > > are planning support for Python later this year. > > > Q: Why is Google charging for instances rather than CPU as in the > > old model? Were customers really asking for this? > > A: CPU time only accounts for a portion of the resources used by App > > Engine. When App Engine runs your code it creates an Instance, this > > is a maximum amount of CPU and Memory that can be used for running a > > set of your code. Even if the CPU is not currently working due to > > waiting for responses, the instance is still resident and considered > > “in use” so, essentially, it still costs Google money. Under the > > current model, apps that have high latency (or in other words stay > > resident for long periods of time without doing anything) are not > > able to scale because it would be cost-prohibitive to Google. So, > > this change is designed to allow developers to run any sort of > > application they would like but pay for all of the resources that are being used. > > > Q: What does this mean for existing customers? > > A: Many customers have optimized for low CPU usage to keep bills > > low, but in turn are often using a large amount of memory (by having > > high latency applications). This new model will encourage low > > latency applications even if it means using larger amounts of CPU. > > > Q: How will always-on work under the new model? > > A: Still determining how this will work, answer coming very soon (no > > seriously, we are almost done). > > > Q: What is the difference between On-demand Instances and Reserved > > Instances? > > A: On-demand Instances have no pre-commitment in terms of the number > > that will be used. You pay for them as you use them. Reserved > > Instances are pre-commitment to a certain number of Instance Hours > > in a week. They are cheaper but you must pay for all the Instance > > Hours that you have pre-committed to whether you use them or not. > > This does not mean they have to be running the whole time. > > > Q: Wait, so Reserved instances don’t mean you have to keep them > > running the whole time? > > A: No, it is just a way to get cheaper instance-hours by > > pre-committing to them. > > > Q: What is the time granularity of the instance pricing? ie if I > > have an instance up for 5 minutes, what am I charged, $0.08 / 60*5? > > A: Instances are charged for their uptime and until they are idle > > for 15 minutes (when the scheduler takes them down). So if you have > > an on-demand Instance only serving traffic for 5 minutes, you will > > pay for 5+15 minutes, or $0.08 / 60 * 20 = 2.6 cents. > > > Q: You seem to be trying to account for RAM in the new model. Will > > I be able to purchase Frontend Instances that use different amounts of memory? > > A: We are only planning on having one size of Frontend Instance. > > > Q: Do Frontend instances handle Task Queues and Cron? > > A: Yes. > > > Q: Can the experimental Go Runtime handle concurrent requests? > > A: Not currently. > > > *Costs* > > Q: Is the $9/app/month a fee or a minimum spend? > > A: *Based on the feedback we’ve received we are changing this $9 fee > > to be a minimum spend rather than a fee a originally listed*. In > > other words you will still have to spend $9/month in order to scale > > but you won’t pay an additional $9 for your first $9 worth of usage > > each month. The $500/account/month will still be a fee as it covers > > the cost of operational support. > > > Q: Will most customers have to move to Paid Apps? > > A: No, we expect the majority of > > ... > > read more » -- 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-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. 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 google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
