Google Code offered in: 中文 - English - Português - Pусский - Español - 日本語
Each application running on Google App Engine is subject to a set of resource quotas that control how much CPU, Bandwidth, and storage space it can consume. During our preview release, all of this usage is free--in the future, developers will be allowed to purchase additional usage beyond these free quotas, but Google App Engine will always be free to get started.
You can always monitor the amount of resources your app has available in real time by checking the Administration Console.
The Google App Engine quota system keeps track of a set of quotas for each application. Each time an application needs to consume a system resource, from CPU cycles to sending an email, the quota levels will be checked; if there is not enough quota remaining, the operation will be denied. The quota levels displayed in the Administration Console apply to a rolling 24 hour time period.
The quota system is designed to ensure that an application is consistently available by spreading resource usage over the course of a day. If your application sustains very heavy traffic for too long, it is possible to see quota denials even though your 24-hour limit has not yet been reached. Sudden spikes in traffic are handled by temporary increases in the rate at which quota can be consumed. This spiking rate gradually backs off over time and will eventually reach steady state at the constant replenishment rate.
Quota | Limit |
Apps per Developer | 10 |
Storage per App | 500MB |
Files per App | 1,000 |
Size per File | 1MB |
All of our quotas are listed in terms of a rolling 24 window, although there are limits on the amount of resources your application can consume during shorter periods of time. As mentioned above, sudden spikes in traffic are handled by increasing the rate at which your app can consume resources, and that rate is gradually reduced again as time goes by. This prevents your application from exhausting all of its daily quota in a short period of time, and ensures it's always available during periods of lowered activity.
The actual quota numbers are as follows:
Quota | Limit |
Emails per Day | 2,000 |
Bandwidth In per Day* | 10,000 MB |
Bandwidth Out per Day* | 10,000 MB |
HTTPS Bandwidth In per Day | 2,000 MB |
HTTPS Bandwidth Out per Day | 2,000 MB |
CPU Megacycles per Day | 200,000,000 |
Total HTTP Requests per Day | 650,000 |
HTTPS Requests per Day | 130,000 |
Datastore API Calls per Day | 2,500,000 |
URLFetch API Calls per Day | 160,000 |
*Data sent and received via HTTPS count against both the HTTPS-specific bandwidth quotas as well as against the overall bandwidth quotas. You may have noticed that your usage of HTTPS bandwidth at times appears to be greater than your overall bandwidth usage. This is because our quota displays use a rolling 24-hour window, and the overall bandwidth quotas are replenished at a faster rate than the HTTPS quotas.
We also place a limit on the number of overly CPU-intensive requests that your application can serve--you'll see warning messages in your logs if your application is in danger of exceeding this quota.
When your application has exceeded a quota related to one of our APIs, those API calls will begin raising an apiproxy_errors.OverQuotaError
exception. Your application should catch those exceptions and handle them appropriately.
For instance, when dealing with requests to the Mail API, you can wrap your request to the Mail API in try/except statement in your application's code. The statement may resemble the code snippet below:
try: mail.SendMessage(to='test@example.com', from='admin@example.com', subject='Test Email', body='Testing') except apiproxy_errors.OverQuotaError, message: # Record the error in your logs logging.error(message) # Display an informative message to the user self.response.out.write('This application can not send email currently, please try again later')
If your application is over quota, that information will be logged and you can display a descriptive message to your users.
If your application has reached its quota for system resource usage, such as Bandwidth In or CPU Megacycles used, your application will start serving an HTTP 403 error stating that your application is over quota. Because each of your application's quotas are replenished continually, your app will serve correctly once the traffic subsides. If you're going over your system resource quota unexpectedly, consider profiling your app's performance. If you're building a very large app and would like to help us test our system, you can apply for higher quotas.
If your application experiences sudden spikes in traffic, Google App Engine will attempt to serve as many of the requests as possible while ensuring your application will be able to serve some traffic throughout the rest of the day.
Consider a situation where requests for your application experience a sudden spike in traffic due to being linked from a popular site. The rate at which your application can consume resources will instantly be increase and initially all of the requests for your application will be served as the traffic starts to increase. This "spike rate" will then gradually decrease in order to ensure your app will continue to serve throughout the day while remaining under the 24-hour quota limits. Once the rate of requests pushes your application beyond this decreasing spike rate, the overage requests will be denied with a 403 error.