App Engine generates usage reports about your application'sperformance and resources utilization. Listed below are potential strategiesfor managing your resources more efficiently. For more information,see thepricing page.

Viewing usage reports

When evaluating application performance, you should check thenumber of instances the application is running, and how the applicationconsumes resources.

View the dashboard usage reports

View the Instances page

The following sections suggest some strategies for managing resources.

Managing dynamic instance scaling

Decreasing latency

Application latency impacts the number of instances that are required to handle yourtraffic. By decreasing latency, you can reduce the number of instances used toserve your application.Cloud Trace is a useful tool to viewdata about latency and understand potential changes to decrease it.

After using Cloud Trace to view your latency, try some of the followingstrategies to reduce latency:

• Increase caching of frequently accessed shared data - That's another wayof saying - use App Engine Memcache. Also, setting your application'scache-control headers can have a significant impact on how efficiently your data iscached by servers and browsers. Even caching things for a few seconds canhave an impact on how efficiently your application serves traffic.Python applications should also make use ofcaching in the runtime.
• Use App Engine Memcache more efficiently - Use batch calls for get,set, delete, etc instead of a series of individual calls.Consider using theMemcache Async API.
• Use tasks for non-request bound functionality- If your applicationperforms work that can be done beyond the scope of a user-facing request,put it in a task! Sending this work toTask Queue instead of waiting forit to complete before returning a response can significantly reduceuser-facing latency. Task Queue can then give you much more control overexecution rates and help smooth out your load.
• Use Firestore in Datastore mode (Datastore) more efficiently - See below for more detail.
• Execute multiple URL Fetch calls in parallel:
  • Batch together multiple URL Fetch calls instead of handling themindividually inside individual user-facing requests, and handle them inan offline task in parallel via async URL Fetch.
  • Use the asyncURL Fetch API.
• For HTTP sessions, write asynchronously.

Change auto-scaling performance settings

Theapp.yamlconfiguration file contains several settings you can use toadjust the trade-off between performance and resource load for a specific versionof your app.For a list of the available auto-scaling settings, seescaling elements.Watch the App EngineNew Scheduler Settingsvideo to see the effects of these settings.

Enable concurrent requests in Python

Your application's instances can serve multiple requestsconcurrently in Python. Enabling this setting will decrease the number ofinstances needed to serve traffic for your application, but your applicationmust be threadsafe in order for this to work correctly. Read about how to useconcurrent requests by enablingthreadsafe in yourapp.yamlfile.

Configuring Task Queue settings

The default settings for Task Queue are tuned for performance. With thesedefaults, when you put several tasks into a queue simultaneously, they willlikely cause new Frontend Instances to start. Here are some suggestions forhow to tune Task Queue to conserve Instance Hours:

• Set the X-AppEngine-FailFast header on tasks that are not latency sensitive.This header instructs the scheduler to immediately fail the request if anexisting instance is not available. Task Queue will retry and back-offuntil an existing instance becomes available to service the request.However, it is important to note that when requests withX-AppEngine-FailFast set occupy existing instances, requests without thatheader set may still cause new instances to be started.

Configure yourTask Queue's settings.

• If you set the "rate" parameter to a lower value, Task Queue willexecute your tasks at a slower rate.
• If you set the "max_concurrent_requests" parameter to a lower value,fewer tasks will be executed simultaneously.

Serve static content where possible

Static content servingin Pythonis handled by specialized App Engine infrastructure, which does not consumeInstance Hours.If you need to set custom headers, use theBlobstore API. The actual servingof the Blob response does not consume Instance Hours.

Managing application storage

App Engine calculates storage costs based on the size of entities in theDatastore, the size of Datastore indexes, the sizeof tasks in the task queue, and the amount of data stored in Blobstore. Here aresome things you can do to make sure you don't store more data than necessary:

• Delete any entities or blobs your application no longer needs.
• Remove any unnecessary indexes, as discussed in theManaging DatastoreUsage section below, to reduce index storage costs.

Managing Datastore usage

App Engine accounts for the number of operations performed inDatastore. Here are a few strategies that can result in reducedDatastore resource consumption, as well as lower latency forrequests to Datastore:

• The Google Cloud console dataviewer displays the number of write opsthat were required to create every entity in your local Datastore.You can use this information to understand the cost of writing each entity.SeeUnderstanding Write Costsfor information on how to interpret this data.
• Remove any unnecessary indexes, which will reduce storage and entity writecosts.Use the"Get Indexes" functionalityto see what indexes are defined on your application.You can see what indexes are currently serving for your application in theGoogle Cloud console Search page.
• When designing your data model, you might be able to write your queries insuch a way so as to avoid custom indexes altogether. ReadQueries and Indexesdocumentation for more information on how App Engine generatesindexes.
• Whenever possible, replace indexed properties (which are the default) withunindexed properties (Python),which reduces the number of Datastore write operations whenyou put an entity. Caution, if you later decide that you do need to be ableto query on the unindexed property, you will need to not only modify yourcode to again use indexed properties, but you will have to run amap reduceover all entities to reput them.
• Due to Datastore query planner improvements inApp Engine 1.5.2 and 1.5.3 releases, your queries may now requirefewer indexes than they did previously. While you may still choose to keepcertain custom indexes for performance reasons, you may be able to deleteothers, reducing storage and entity write costs.
• Reconfigure your data model so that you canreplace queries with fetch bykeywhich is cheaper and more efficient.
• Use keys-only queries instead of entity queries when possible.
• To decrease latency, replace multiple entityget()s with a batchget().
• Use Datastore cursors for pagination rather than offset.
• Parallelize multiple Datastore RPCs via theasync datastore API.

Note: Small Datastore operations include calls to allocateDatastore ids or keys-only queries. See thepricing page for more information on costs.

Managing bandwidth

To reduce outgoing bandwidth, you canset the appropriateCache-Control header on your responses and set reasonable expiration timesfor static files. Using publicCache-Control headers in this way will allowproxy servers and your clients' browser to cache responses for the designatedperiod of time.

Incoming bandwidth is more difficult to control, since that's the amount ofdata your users are sending to your app. However, you can useApp Engine firewall rules,to allow or restrict ranges of IP addresses and subnets.

Managing other resources

One of the best strategies for auditing your usage of the Email APIis to useAppstats to makesure you're not making more calls than are necessary.It's always a good idea to makesure you are checking your error rates and looking out for any invalid callsyou might be making. In some cases it might be possible to catch those callsearly.