Skip to page content Skip to main navigation
English | Site Directory

e.g. "templates" or "datastore"

# Google App Engine General Questions

- What languages are supported by Google App Engine?
- What frameworks does Google App Engine Support?
- Can I still develop a Google App Engine app if I don't have an account?
- How many applications can I create with Google App Engine?
- How can I disable one of my existing applications?
- What type of content is allowed on Google App Engine?
- How do I read the system usage charts in the admin console for my app?
- How is the current load report in my application's admin console generated?
- How do you generate the list of URIs showing the most errors in my application's admin console?
- What is GQL?
- Why do my queries need to be covered by indexes, and how do I include them?
- Why were my indexes marked as Error?
- Why do my indexes stay Building or Deleting for long periods of time?
- How do I authenticate users of my application?
- Are there any Python libraries not supported by Google App Engine?
- Why did my app get disabled?
- Why is my app over quota?
- Why do my logs show "This request used a high amount of CPU"?
- How do I report an application that is in violation of your Terms and Conditions?
- Should I use the SDK for serving external requests?
- How do I serve compressed content?
- Does Google App Engine support SSL (HTTPS)?
- Can I use SSL (HTTPS) on App Engine with my Google Apps domain?

## What languages are supported by Google App Engine?

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.

## What frameworks does Google App Engine Support?

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.

## Can I still develop a Google App Engine app if I don't have an account?

Absolutely! Even if you don't yet have a Google App Engine account you can always download our SDK and start development.

## How many applications can I create with Google App Engine?

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.

## How can I disable one of my existing applications?

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.

## What type of content is allowed on Google App Engine?

Please see our Terms of Service if you have questions on what kind of content is allowed with Google App Engine.

## How do I read the system usage charts in the admin console for my app?

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:

- Requests per Second: The number of URIs requested from your application every second
- Errors per Second: The number of errors generated by your application every second
- Bytes Received per Second: The number of bytes that are received in a request every second
- Bytes Sent per Second: The number of bytes sent in a request every second
- Megacycles per Second: The amount of CPU megacyles your application uses every second
- Milliseconds Used per Second: The number of milliseconds per second your app is handling a request
- Number of Quota Denials per Second: The number of times a request to your application has be denied due to quota restraints. A full description of the quota limits in our preview release can be found here.

## How is the current load report in my application's admin console generated?

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.

## How do you generate the list of URIs showing the most errors in my application's admin console?

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

## What is GQL?

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.

## Why do my queries need to be covered by indexes, and how do I include them?

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.

## Why were my indexes marked as Error?

They're probably exploding indexes. Occasionally, though, we have to move indexes into Error manually. We usually contact you directly when we do this.

## Why do my indexes stay Building or Deleting for long periods of time?

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.

## How do I authenticate users of my application?

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.

## Are there any Python libraries not supported by Google App Engine?

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:

- Libraries that maintain databases on disk are not enabled in Python for Google App Engine
- Sockets are disabled with Google App Engine
- The system does not allow you to invoke subprocesses, as a result some os module methods are disabled
- Threading is not available
- For security reasons, most C-based modules are disabled
- Other features that are limited:
  - marshal is disabled
  - cPickle is aliased to pickle
  - System calls have been disabled

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).

## Why did my app get disabled?

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.

## Why is my app over quota?

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.

## Why do my logs show "This request used a high amount of CPU"?

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:

1. Runtime CPU: used by the code you uploaded with your app
2. API CPU: used in App Engine API calls (datastore API operations, urlfetch API, image API, etc.)

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:

- On the app dashboard, the graph of Megacycles/Request
- The quota bar for "CPU Used" on the app dashboard
- The table of average total CPU usage for each of the top requested URLs

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.

## How do I report an application that is in violation of your Terms and Conditions?

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.

## Should I use the SDK for serving external requests?

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.

## How do I serve compressed content?

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.

## Does Google App Engine support SSL (HTTPS)?

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

## Can I use SSL (HTTPS) on App Engine with my Google Apps domain?

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.