Hi Gijsbert, both of these are indeed still accurate. Greg
On Mon, Jul 4, 2011 at 6:28 AM, Gijsbert <[email protected]> wrote: > Greg, can you confirm if a channel in the new pricing scheme is still > available for 2 hours and can be reused for multiple clients (as long > as they don't overlap in time)? > > On Jul 3, 1:39 pm, ksafez216 <[email protected]> wrote: > > You say that the new Channel API rates is what users pay today. > > > > First of all, in the original model you get over 8,000 free channels a > > day to 100/day in the new model. > > > > And please tell me if 1000's of users are exchanging messages on > > individual channels, does that mean that there will be have to 1000's > > of instances running at the same time? > > > > Things should get cheaper and simpler, not more expensive and more > > complicated! > > > > On May 17, 9:49 pm, "Gregory D'alesandre" <[email protected]> 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... > > > > 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 [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.
