Google Code offered in: 中文 - English - Português - Pусский - Español - 日本語
Currently, Google App Engine allows you to write your applications with Python 2.5. For security reasons, some Python modules written in C are disabled in our system. Also, since Google App Engine doesn't support writing to disk, some libraries that support this and other functionalities are only partially enabled. Our developer documentation gives a good overview of the Python runtime environment. A description and full reference of Python libraries that are disabled or partially disabled can be found here.
Additionally, your website templates can include Javascript along with your HTML. Among other things, this allows you to write webservices that make use of Ajax web development techniques.
Google App Engine allows most python web frameworks to be uploaded with your application. These web frameworks should need little or no modification to work with our system. For your convenience, Django v0.96.1 is included with the Google App Engine SDK.
Absolutely! Even if you don't yet have a Google App Engine account you can always download our SDK and start development.
During the Google App Engine preview release, each developer can create 10 applications with their Google App Engine administrator account. At this time, once an application is created, you may not delete the application.
If you would like to disable an existing application, first you should remove the handlers from your application's app.yaml
file. Add a handler to your app.yaml file that points to a non-existent file. Using appcfg.py, upload the blank app.yaml
file. Once the new app.yaml
file is uploaded, your application will be disabled.
Please see our Terms of Service if you have questions on what kind of content is allowed with Google App Engine.
Your Google App Engine dashboard in the Admin Console has six graphs that give you a quick visual reference of your system usage. The information displayed in these graphs gives you a 6 hour snap shot of resource consumption per second. Here are a list of the graphs you will see in the Admin Console:
The current load gives a breakdown of the number of requests for each URI requested from your application, as well as some CPU stats for the URI. The request parameters are omitted from the path.
The leftmost column lists the URI path, starting with the most popular URI by total requests, which is listed under the "Requests" column. The number of requests is reset every Midnight PST. The "Req./Min." column lists the short-term request rate of each URI. Under high load, this column will become "Req./S.".
The current load table provides two data points for CPU usage, "Avg. CPU" and "% CPU". The "Avg. CPU" displays the average amount of CPU in Megacycles a request to that URI has consumed over the past hour. The "%CPU" column shows the percentage of CPU that URI has consumed since Midnight PST, with respect to the other URIs in your application.
If any error occurs when attempting to load a URI, our system records that error. We then show the URIs that record the most errors in the past 24 hrs in the admin console. In addition to showing the total number of errors, we include the percentage of errors as the ratio of errors at the URI to total requests of that URI.
Applications who have not included a favicon.ico file may notice the URI /favicon.ico
on the list of errorful URIs. Favicon.ico is a file that is requested by a user's web browser when it attempts to load the page. Favicon.ico is your website's icon, and is typically displayed in the user's browser URL bar, next to the web address of your site.
For your application, favicon.ico should be a static image. You can upload a favicon.ico file with your application, and in your app.yaml file configure your application to serve the image when the url /favicon.ico is requested. Below is an example entry in your app.yaml
file for /favicon.ico
. We assume you include the favicon.ico file in the directory path static/images
:
- url: /favicon.ico static_files: static/images/favicon.ico upload: static/images/favicon.ico
GQL is a query language that is used with the Google App Engine datastore. It uses a SQL like syntax to retrieve entire entities from your application's datastore, and includes the ability to filter on properties, specify the sorting order of the results, and limit the number of entities returned. The full GQL language reference can be found here.
If you run a query that filters on multiple entity properties, or orders your entities in a descending order, you will need an index for that query. You must have an index for every query of that kind that you run with your application. The datastore index for a query maintains and updates a list of keys sorted in the manner that the query specifies to allow speedy access to the data in your datastore. A full explanation of datastore indexes can be found in our documentation.
When you develop your application with Google App Engine SDK, every query you run automatically gets indexed when necessary. If you thoroughly test your application before uploading it to your website, all of the indexes your application will need will be included in your application's index.yaml
file. You may manually add indexes to index.yaml
if you find a query that was not covered by your development testing. Our documentation includes information on how to write indexes for your application.
They're probably exploding indexes. Occasionally, though, we have to move indexes into Error manually. We usually contact you directly when we do this.
In the past, this has usually happened because worker shards were too large to be completed within the lease period. We initially addressed this by increasing the lease period. Later, we started splitting individual tablets into shards.
Our Users API allows you to authenticate users with Google Accounts, or against user accounts of your own Google Apps domain. These two forms of authentication can not be used with the same application. Please read our article on how to configure your application to authenticate against a Google Apps domain.
With our Users API, when your application requests a user sign in, they are directed to a Google sign in page where the user enters his or her username and password. The user is returned to your website, and the user credentials are communicated to your application through the Users property.
A small percentage of native C python modules, and subsets of native C python modules are not available with Google App Engine. A full list detailing native C Python module support can be found here. The disabled modules fall in to the following categories:
Please keep in mind that third party packages which use any of the above features will not function with Google App Engine (packages such as mysql, postgresql, etc).
An app may be disabled if it fails to abide by our Terms and Conditions. Additionally, during the preview release, if an application is found to be using an inordinate amount of system resources due to a bug or other issue leading to inefficient resource usage, we may disable the app so that the developer can fix the development issues using our development SDK before re-enabling the application on Google App Engine.
In our preview release, we have system quotas that limit the amount of traffic and system resources. You can read the entire breakdown of system quotas here. The current quota, with typical system usage, allows approximately 5 million pageviews a month. Though to prevent your application from running through its quota too quickly, we allocate quota over the course of the month.
With this system, if your application consumes a lot of quota in a short amount of time, you will be able to start serving traffic again more quickly. If your system runs out of system resources on a regular basis, you may apply for an increase in your quota. Please note that we do not guarantee that your quota will be increased, and each application is considered on an individual basis.
The current CPU per request limits are in place to ensure that all App Engine apps remain stable and responsive. Since your app runs on the same machines as other apps, it is important to ensure that no single app or single request can lock out other apps.
The CPU used in requests is measured in two different flavors:
The admin console tracks runtime CPU and records excessive per-request usage in the logs. To see if a request went over the runtime CPU limit, look for:
This request used a high amount of CPU, and was roughly X times over the average request CPU limit. High CPU requests have a small quota, and if you exceed this quota, your app will be temporarily disabled.
The amount of CPU indicated for each request in the logs summary is a combination of the Runtime and API CPU (datastore, urlfetch, image manipulation, etc.).
The combined API + Runtime value of CPU usage is displayed in the following places in the Admin Console:
High datastore CPU usage can indicate a design flaw which will prevent your app from scaling in its use of the datastore. Write contention or inefficient queries can lead to timeouts on datastore operations which you will need to handle on your app code.
If your requests are consuming too much runtime CPU (as indicated within the log warnings) at too high a rate, requests to your app will temporarily be denied. For this reason it is important to identify frequent sources of high runtime CPU requests and optimize the code.
A request is counted as a "High CPU Request" if it uses more than one thousand runtime CPU megacycles. For now, your app receives 2 "High CPU Request Credits" per minute, and can store up to 60 of these credits at any one time.
In the future, we plan to reduce the impact of high CPU requests on the server, but for now you'll need to optimize expensive portions of your app in order to maintain throughput for the App Engine system as a whole. For tips on optimizing your app, see our memcache API documentation, or Brett Slatkin's talk on scalability from Google I/O in the spring of 2008.
To report an application that is in violation of the Google App Engine Terms and Condition, please contact us. We will determine if the application is in violation, and if necessary, contact the application's developer over the violation.
The dev_appserver is designed for local testing and disallows external connections by default. You can override this using the -a <hostname> flag when running it, but doing so is not recommended because the SDK has not been hardened for security and may contain vulnerabilities.
Google App Engine does its best to serve gzipped content to browsers that support it. Taking advantage of this scheme is automatic and requires no modifications to applications.
We use a combination of request headers (Accept-Encoding, User-Agent) and response headers (Content-Type) to determine whether or not the end-user can take advantage of gzipped content. This approach avoids some well-known bugs with gzipped content in popular browsers. To force gzipped content to be served, clients may supply 'gzip' as the value of both the Accept-Encoding and User-Agent request headers. Content will never be gzipped if no Accept-Encoding header is present.
Google App Engine allows you to serve SSL (HTTPS) traffic through your appspot.com domain. Simply add the 'secure' parameter to your app.yaml handler for the URLs through which you wish to support secure traffic. For complete information on how to configure your application for secure traffic, please see our documentation
All secure traffic with Google App Engine must be served from your appspot.com domain (https://your-app-id.appspot.com). If you are serving your app off of a Google Apps domain, you must direct all secure traffic through your app's appspot domain.