Some Administration Console settings let you tune your application's performance. In some cases, you want to optimize to minimize cost. In other cases, you want to serve heavy request volume quickly. These controls allow you to
- Set the Frontend Instance Class. Your application can use faster, "bigger," more expensive servers.
- Configure the Scheduler. The App Engine scheduler controls how your application responds to increased load. As more requests come in, the scheduler might start up more servers or queue incoming requests.
- Let PageSpeed Service Optimize HTML Serving. This service optimizes the way your application serves web content: it compresses and caches. It can inline and combine resources.
Setting the Frontend Instance Class
App Engine provides three different classes of frontend instances, each with different memory and and CPU limits. These classes allow you to configure your frontend instance with the processing capacity you need to perform your work. Each class has a specific hourly billing rate. Please see Billable Quota Unit Costs for pricing.
Important: Currently, when you are billed for instance hours, you will not see any instance classes in your billing line items. Instead, you will see the appropriate multiple of instance hours. For example, if you use an F4 instance for one hour, you do not see "F4" listed, but you will see billing for four instance hours at the F1 rate.
The default class for frontends is F1, which gives you 128MB of memory and 600MHz of CPU capacity. You can change the class of the frontend using the performance settings in the admin console.
The Frontend Instance Class setting is selected by choosing one of the values in the dropdown menu. Each value represents a memory size and processing power, with larger memory sizes and processing power providing extra performance but at an increased cost. The value you select is used for all of the instances used by all versions of your app.
Note: Specifying the frontend instance class does not affect backend instances.
You can change the current frontend instance class for your app at any time. Python and Go apps automatically get the new instance class that you choose. A Java app must be restarted to get the new instance class.
Frontend instances are priced based on an hourly rate determined by the frontend class. The following table describes the cost for each class:
|Frontend class||Memory limit||CPU limit||Cost per hour per instance|
Configuring the Scheduler
App Engine's scheduler is responsible for routing incoming requests to be served by your app's instances. Sometimes the volume of incoming requests exceeds the capacity of the instances currently available to your app. When this happens, incoming requests may have to wait in the Pending Queue until busy instances become available, or until the scheduler starts new instances.
The scheduler is responsible for deciding how to serve your app's request load. Under regular conditions, it may spin up new idle instances to absorb traffic and minimize latency in the event of a sudden load spike. Because new instances take time to create, unusually heavy surges of traffic may consume all available idle instances faster than the scheduler can create new ones. This can cause your users to experience delays (latency) in the serving of requests.
The default settings enable App Engine's scheduling algorithm to scale the number of instances based on your recent request load and latency profile. If you use manual settings instead, you may need to adjust them continually as your request volume changes.
Setting the Number of Idle Instances
The Idle Instances sliders control the minimum and maximum number of idle instances available to your application at any given time.
The upper slider sets the minimum number of idle instances:
Note: In order to specify the minimum number of idle instances, you must have a paid app.
- A low minimum helps keep your running costs down during idle periods, but means that fewer instances may be immediately available to respond to a sudden load spike.
- A high minimum allows you to prime the application for rapid spikes in request load. App Engine keeps that number of instances in reserve at all times, so an instance is always available to serve an incoming request, but you pay for those instances. This functionality replaces the deprecated "Always On" feature, which ensured that a fixed number of instances were always available for your application. Once you've set the minimum number of idle instances, you can see these instances marked as "Resident" in the Instances tab of the Admin Console.
Note: If you set a minimum number of idle instances, the pending latency slider will have less effect on your application's performance. Because App Engine keeps idle instances in reserve, it is unlikely that requests will enter the pending queue except in exceptionally high load spikes. You will need to test your application and expected traffic volume to determine the ideal number of instances to keep in reserve.
The lower slider controls the maximum number of idle instances (up to 100):
- A high maximum reduces the number of idle instances more gradually when load levels return to normal after a spike. This helps your application maintain steady performance through fluctuations in request load, but also raises the number of idle instances (and consequent running costs) during such periods of heavy load.
- A low maximum keeps running costs lower, but can degrade performance in the face of volatile load levels.
Note: When settling back to normal levels after a load spike, the number of idle instances may temporarily exceed your specified maximum. However, you will not be charged for more instances than the maximum number you've specified.
Setting the Pending Latency
Note: In order to specify the maximum pending latency, you must have a paid app.
Pending request latency arises when all of your application's available instances are too busy to serve new requests. When this happens, incoming requests go to a pending request queue. The scheduler automatically manages creation of new instances for pending requests, but you can adjust its behavior through minimum and maximum latency settings. These settings effectively control how long a request waits in the pending queue when there are no available instances: no less than the minimum, and no more than the maximum.
The App Engine scheduler will always wait until the specified minimum latency for a free instance to become available. Once the minimum is reached, it applies heuristics to determine if and when to start a new instance. (Waiting for an existing instance to become free may be faster than starting a new one.) If the request is still pending when the specified maximum latency is reached, App Engine immediately starts a new instance to serve it.
Note: If you set a minimum number of idle instances, the Pending Latency controls will have little or no effect on your app's performance. See Minimum Idle Instances for more information.
The first Pending Latency slider sets the minimum period of time (at least 10 milliseconds) that the scheduler will wait for a free instance to serve the request.
- A low minimum means requests must spend less time in the pending queue when all existing instances are active. This improves performance but increases the cost of running your application.
- A high minimum means requests will remain pending longer if all existing instances are active. This lowers running costs but increases the time users must wait for their requests to be served.
The second slider sets the maximum period of time (at most 15 seconds) that the scheduler will wait before resolving to create a new instance for the request.
- A low maximum means App Engine will start new instances sooner for pending requests, improving performance but raising running costs.
- A high maximum means users may wait longer for their requests to be served (if there are pending requests and no idle instances to serve them), but your application will cost less to run.
Enabling PageSpeed Optimization Service
App Engine's support for PageSpeed is an experimental, innovative, and rapidly changing new feature for Google App Engine. Unfortunately, being on the bleeding edge means that we may make backwards-incompatible changes to App Engine's support for PageSpeed. We will inform the community when this feature is no longer experimental.
PageSpeed is a family of tools for optimizing the performance of web pages. App Engine offers PageSpeed as a service; it automatically optimizes your application. There is a small fee for using PageSpeed ($0.39 per gigabyte of bandwidth in addition to regular bandwidth charges), but fast pages create a better user experience and lead to increased traffic and reduced bounce rates, which might improve your business overall. (If your application uses the deprecated Master/Slave datastore instead of the newer High Replication Datastore, PageSpeed isn't compatible.) PageSpeed doesn't touch some types of requests (such as POSTs), so don't be surprised if some non-PageSpeed requests arrive.
If your application tries to serve a large response (more than 32Mb)
through PageSpeed, PageSpeed truncates it at 32Mb. If your application
serves large things like this (audio, video, "big data"), then add their
URLs to PageSpeed's blacklist in the PageSpeed configuration in your
app.yaml file (Python, Go) or
appengine-web.xml file (Java).
You must have billing enabled to use the PageSpeed service. To enable billing, go to the Administration>Application Settings section of the Admin Console, click the Enable PageSpeed Service checkbox, and click Save Settings.
When the PageSpeed service is enabled, it is applied globally to your application. All versions of your app are optimized using the configuration of the most-recently updated version. To measure PageSpeed's improvements without turning it on for every running version, use the PageSpeed Service comparison tool. This tool measures how much faster a specific page will display using PageSpeed's default configuration.
When you activate the PageSpeed service for an application, the default
configuration is applied. You can create a custom configuration by adding a
pagespeed section to the appropriate configuration file:
app.yaml (Python, Go),
app.yaml (PHP), or
PageSpeed works well with most sites but custom configurations can contain aggressive optimizations that may break some Web pages. Before applying a custom configuration to your live site, you should test your site's behavior and ensure that all pages are displayed correctly.
You can test your site by installing and running the App Engine PageSpeed Service Preview extension for the Chrome Web browser. This extension allows you to view your site with the PageSpeed optimizations applied, and verify that your pages display correctly. (Note that the extension does not measure your PageSpeed speed-up.) Follow these instructions:
- If PageSpeed is enabled for your application, disable it in the Application Settings screen of the Administration Console.
- Edit your application configuration and upload it.
- Run Google Chrome. Click on the extension. (It displays as an App Engine icon.) A small dialog box should appear.
- In the dialog box, enter your application's URL in the form
your_app_id.appspot.comand check the "Preview PageSpeed Service" checkbox. Your browser is now configured to send this domain's requests through the PageSpeed Service.
- Navigate to your application's pages. See what your site looks like when optimized. We recommend reloading each page a few times, as the PageSpeed Service needs to process a page few times before it is fully optimized.
- If you encounter any issues with pages not rendering correctly, modify your PageSpeed configuration file to disable PageSpeed for the broken URLs, and preview your site again.
When your configuration and site are working well, enable PageSpeed for your site in the Application Settings screen of the Administration Console.