Region ID
The REGION_ID
is an abbreviated code that Google assigns
based on the region you select when you create your app. The code does not
correspond to a country or province, even though some region IDs may appear
similar to commonly used country and province codes. For apps created after
February 2020, REGION_ID
.r
is included in
App Engine URLs. For existing apps created before this date, the
region ID is optional in the URL.
Learn more about region IDs .
You configure your App Engine app's settings in the app.yaml
file.
This file specifies how URL paths correspond to request handlers and
static files.
The app.yaml
file also contains information about your
app's code, such as the runtime and the latest version
identifier.
Each service
in your app has its own app.yaml
file, which acts as a descriptor for its
deployment. You must first create the app.yaml
file for the default
service
before you can create and deploy app.yaml
files for additional services within
your app.
Directory structure
To learn more about structuring multiple services in your app, see Structuring Web Services in App Engine .Example
The following is an example of an app.yaml
file for a Python 2
application:
runtime : python27 api_version : 1 threadsafe : true handlers : - url : / script : home.app - url : /index\.html script : home.app - url : /stylesheets static_dir : stylesheets - url : /(.*\.(gif|png|jpg))$ static_files : static/\1 upload : static/.*\.(gif|png|jpg)$ - url : /admin/.* script : admin.app login : admin - url : /.* script : not_found.app
A script:
directive can contain either a filepath ending in .py
, which
means the script uses CGI, or a Python modulepath, with package names
separated by dots, which means the script uses WSGI.
Syntax
The syntax of app.yaml
is the YAML format
.
The YAML format supports comments. A line that begins with a pound ( #
)
character is ignored:
# This is a comment.
URL and file path patterns use POSIX extended regular expression
syntax
, excluding collating
elements and collation classes. Back-references to grouped matches (e.g. \1
)
are supported, as are these Perl extensions: \w \W \s \S \d \D
.
Runtime and app elements
application
The recommended approach is to remove the application
element from your app.yaml
file and instead, use a
command-line flag to specify your application ID:
- To use the
gcloud app deploycommand, you must specify the--projectflag:gcloud app deploy --project [ YOUR_PROJECT_ID ]
For more information about using these commands, see Deploying Your App .
The application ID is the Google Cloud console project ID that you specified when you created the application in the Google Cloud console .
api_version
Required. The version of the API in the given runtime environment that is used by your app.
This field is deprecated in newer App Engine runtimes .
When Google announces support for a new version of a
runtime environment's API, your deployed app will continue to use the
one for which it was written. To upgrade your app to a new version of
the API, you change this value and then redeploy your app to App
Engine. When you specify the 1
value, the latest supported runtime environment is used each time you
deploy that app (currently
).
At this time, App Engine has one version of the python27
runtime environment: 1
auto_id_policy
-
default - Default. Uses scattered auto IDs that are large well-distributed integers that are small enough to be represented by 64-bit floats.
-
legacy - The legacy option will be deprecated in a future release and will eventually be removed. For more information, see the blog post announcing this change .
builtins
Optional.
The Python 2 SDK includes a number of built-in handlers for
common application functions. The builtins
directive
allows you to include specific handlers in app.yaml
.
This field is deprecated in the Python 3 runtime .
The following built-in handlers are available for your use:
-
appstats - Enables Appstats
at
/_ah/stats/, which you can use to measure your application's performance. In order to use Appstats, you also need to install the event recorder . -
deferred - Enables the deferred handler at
/_ah/queue/deferred. This builtin allows developers to usedeferred.defer()to simplify the creation of Task Queue tasks. -
remote_api - Enables the
remote_apibuiltin at/_ah/remote_api/. This builtin allows remote applications with the proper credentials to access the datastore remotely.
builtins : - deferred : on - appstats : on
The builtins
directive is a special instance of the includes
directive. Each builtin
directive
is equivalent, in Python, to an includes
directive with
an expanded path. For example:
builtins : - name : on
Is equivalent to:
includes : - $PYTHON_LIB/google/appengine/ext/builtins/name/
When you use builtins
in your app.yaml
file,
any handlers that are defined by in the built-in include.yaml
file will supersede any handlers that you
define in your app.yaml
file. However, if you include a
file that then uses builtins
or includes
,
the handlers are added by order of the include hierarchy. In other
words, the handlers of the "parent" include are added before the
builtins of the "child" includes, and so on.
For example, consider the following app.yaml
, which uses
the built-in appstats
handlers:
handlers : - url : /.* script : main.app builtins : - appstats : on
The resulting list of handlers is:
[ /_ah/stats , /.* ]
If the app.yaml
uses an includes
directive:
includes : - included.yaml
And the included.yaml
file uses builtins
:
handlers : - url : /.* script : main.app builtins : - appstats : on
The resultant list of handlers is now:
[ /.* , /_ah/stats ]
The order of placement of the builtins
clause in a .yaml
file doesn't change the behavior.
default_expiration
Optional. Sets a global default cache period for all static
file handlers for an application. You can also configure a cache duration for specific static file
handlers
. The value is a string of numbers and units, separated by
spaces, where units can be d for days, h for hours, m for minutes, and
s for seconds. For example, "4d 5h"
sets cache expiration
to 4 days and 5 hours after the file is first requested. If omitted,
the production server sets the expiration to 10 minutes.
runtime : python27 api_version : 1 threadsafe : true default_expiration : "4d 5h" handlers : # ...
For more information, see Cache expiration .
Optional.
You can define environment variables in your app.yaml
file to make them available to your app. Ensure that the key in Environment variable(s) matches the expression '[a-zA-Z_][a-zA-Z0-9_]*' (start with alphabet or "_" followed by any alphanumeric or "_").
Environment variables that are prefixed with GAE
are reserved for system use and not allowed in the app.yaml
file.
os.environ
dictionary: env_variables : DJANGO_SETTINGS_MODULE : "myapp.settings"
error_handlers
Optional. Used to configure custom error pages that are returned for different error types.
This element can contain the following elements:
-
error_code - Optional. The
error_codecan be one of the following:-
over_quota - Indicates the app has exceeded a resource quota
-
timeout - Served if a deadline is reached before there is a response from your app.
The error_code is optional; if it's not specified, the given file is the default error response for your app.
-
-
file - Each file entry indicates a static file that should be served in
place of the generic error response. If you specify a
fileelement without a correspondingerror_codeelement, the static file will be the default error page for your app. The custom error data must be less than 10 kilobytes.
error_handlers : - file : default_error.html - error_code : over_quota file : over_quota.html
handlers
Required. A list of URL patterns and descriptions of how they should be handled. App Engine can handle URLs by executing application code, or by serving static files uploaded with the code, such as images, CSS, or JavaScript.
Optional.
The includes
directive allows you to include the
configuration file for any library or service throughout your
application. For example, you might include a user administration
library as follows:
includes : - lib/user_admin.yaml
App Engine resolves the included path in the following order:
- Absolute or relative path to the working directory. The specified path resolves to a file.
- Relative to the application's directory, which is also known as the basepath . The basepath and path resolve to a file.
- Relative to the file that included the current file. The location of the referring file and the include path resolve to the included file.
If the include
directive specifies a directory, then App
Engine looks in that directory for a file called include.yaml
. If the include directive is a file, then
that specific file is included. Using includes
retrieves
only the following types of directives from the destination file (if
present):
Included skip_files
patterns are added to those in the
including app.yaml
, or to the default list if there is no
explicit list in app.yaml
. Note that skip_files
compares absolute paths.
inbound_services
Optional.
Applications must enable those services before it can receive inbound
requests. You can enable the service for a Python 2 app
by including an inbound_services
section in the app.yaml
file.
The following inbound services are available:
-
mail - Allows your application to receive mail .
-
warmup - Enables warmup requests. See Configuring Warmup Requests .
inbound_services : - mail - warmup
instance_class
Optional. The instance class for this service.
The following values are available depending on your service's scaling :
- Automatic scaling
-
F1,F2,F4,F4_1G - Default:
F1Optionally use the
automatic_scalingelement to change default settings for automatic scaling, such as minimum and maximum number of instances, latency, and concurrent connections.Note:If
instance_classis set toF2or higher, you can optimize your instances by settingmax_concurrent_requeststo a value higher than the default value of 10. To determine the optimal value, gradually increase it and monitor the performance of your application. - Basic and manual scaling
-
B1,B2,B4,B4_1G,B8 - Default:
B2Basic and manual instance classes require you to specify either the
basic_scalingelement or themanual_scalingelement.
libraries
Optional.
The Python 2.7 runtime includes some third-party
libraries
. Some of these are available by default; others are only
available if configured. You can specify which version you want to use
by specifying the name
and version
values.
This field is deprecated in the Python 3 runtime .
libraries : - name : PIL version : "1.1.7" - name : webob version : "latest"
Note than when you specify latest
, the SDK determines
the latest library version at deployment time
. Once
deployed, the library version will not change. The only way to get a
different version of the library is to deploy again.
If you're developing an application that doesn't have users yet: you don't need to track new versions. But if your application is being actively used, beware: you might be surprised that your application starts using a new not-backward-compatible library version.
For a list of the included third-party libraries, see Third-party Libraries . You can use additional pure-python third-party libraries by installing them into a local directory .
If you are using the flexible environment, see Using Python libraries in the flexible environment .
module
Note:Modules are now named Services.
To manage your app with the gcloud CLI, use the service element instead.
runtime
Required. The name of the runtime environment that is used by your app. For example, to specify Python 2.7, use:
runtime : python27
service
Services were formerly known as Modules.
Supported only by the gcloud CLI or gcloud CLI-based
plugins, for example: gcloud app deploy
.
Required if creating a service
.
Optional for the default
service. Each service and each version must have a name. A name can
contain numbers, letters, and hyphens. The combined length of VERSION-dot-SERVICE-dot-PROJECT_ID
, where VERSION
is the name of
your version, SERVICE
is the name of your service, and PROJECT_ID
is your project ID, cannot be longer than 63 characters and cannot
start or end with a hyphen. Choose a unique name for each service
and each version. Don't reuse names between services and versions.
service : service-name
Note:The gcloud app
deploy
command is backwards
compatible and supports existing app.yaml
files that
include services declared as modules, for example:
module : service-name
service_account
Optional. The service_account
element lets you specify a user-managed service account
as the identity for the version. The specified service account is used when accessing other Google Cloud services and executing tasks.
service_account : [ SERVICE_ACCOUNT_NAME ] @ [ PROJECT_ID ] . iam.gserviceaccount.com
skip_files
Optional.
The skip_files
element specifies which files in the
application directory are not to be uploaded to App Engine.
The value is either a regular expression, or a list of regular
expressions. Any filename that matches any of the regular expressions
is omitted from the list of files to upload when the application is
uploaded. Filenames are relative to the project directory.
The skip_files
has the following default:
skip_files : - ^(.*/)?#.*#$ - ^(.*/)?.*~$ - ^(.*/)?.*\.py[co]$ - ^(.*/)?.*/RCS/.*$ - ^(.*/)?\..*$
The default pattern excludes Emacs backup files with names of the form #...#
and ...~
, .pyc
and .pyo
files, files in an RCS
revision control
directory, and Unix hidden files with names beginning with a dot
( .
).
To extend the above regular expression list, copy and paste the above
list into your app.yaml
and add your own regular
expressions. For example, to skip files whose names end in .bak
in addition to the default patterns, add an entry
like this for skip_files
:
skip_files : - ^(.*/)?#.*#$ - ^(.*/)?.*~$ - ^(.*/)?.*\.py[co]$ - ^(.*/)?.*/RCS/.*$ - ^(.*/)?\..*$ - ^(.*/)?.*\.bak$
To skip a full directory, add the directory name to
the list. For example, to skip a directory named logs
,
add the following line to the previously described ones:
skip_files : - logs/
threadsafe
Required.
Configures your application to use concurrent requests. If using
Python's threading library
, the
thread-local data, as returned by threading.local()
, is
cleared after each request.
This field is deprecated in the Python 3 runtime .
threadsafe : [ true | false ]
Note: The threadsafe
directive is required for
Python 2.7 applications. threadsafe: true
requires that all script handlers be
WSGI ones. That is, each script must be specified in a script:
directive a using Python modulepath, with package names separated by dots. The last component of a script:
directive using a Python modulepath is the name of a global variable in the service:
that variable
must be a WSGI app, and is usually called app
by
convention.
version
The recommended approach is to remove the version
element from your app.yaml
file and instead, use a
command-line flag to specify your version ID:
- To use the
gcloud app deploycommand, you specify the-vflag:gcloud app deploy -v [YOUR_VERSION_ID]
For more information about using this command, see Deploying Your App .
An identifier for the version of your application code that you deploy to App Engine.
The version ID can contain lowercase letters, digits, and hyphens. It
cannot begin with the prefix ah-
and the names default
and latest
are reserved and cannot
be used.
Note: Version names should begin with a letter, to distinguish them
from numeric instances which are always specified by a number. This
avoids the ambiguity with URLs like 123-dot-my-service.uc.r.appspot.com
, which can be interpreted
two ways: If version "123" exists, the target will be version "123"
of the given service. If that version does not exist, the target will
be instance number 123 of the default version of the service.
Each version of an application retains its own copy of app.yaml
. When an application is uploaded, the version
mentioned in the app.yaml
file being uploaded is the
version that gets created or replaced by the upload. An administrator
can change which version of the application is serving traffic by
using the Google Cloud console
, and can also test
other versions before configuring them to receive traffic
.
vpc_access_connector
Optional. Configures your application to use a Serverless VPC Access connector, enabling the application to send requests to internal resources in your VPC network. For more information, see Connecting to a VPC network .
-
name - String literal. Specify the fully-qualified name of your
Serverless VPC Access connector in quotes:
"projects/ PROJECT_ID /locations/ REGION /connectors/ CONNECTOR_NAME " -
egress_setting - Optional. Default is
private-ranges-only. Theegress_settingcan be one of the following:-
private-ranges-only - Default. Requests to internal IP addresses are sent through the Serverless VPC Access connector into the connected VPC network. Requests to external IP addresses are sent to the public internet.
-
all-traffic - All requests are sent through the Serverless VPC Access connector into the connected VPC network.
-
vpc_access_connector : name : "projects/ PROJECT_ID /locations/ REGION /connectors/ CONNECTOR_NAME " egress_setting : all-traffic
Handlers element
The handlers
element is a required element in the app.yaml
configuration file. The element provides a list of URL
patterns and descriptions of how they should be handled. App Engine can
handle URLs by executing application code, or by serving static files uploaded
with the code, such as images, CSS, or JavaScript.
Patterns are evaluated in the order they appear in the app.yaml
file, from
top to bottom. The first mapping whose pattern matches the URL is the one used
to handle the request.
The following table lists the subelements of the handlers
element that control
the behavior for scripts, static files,
static directories, and other settings.
application_readable
This field is deprecated in newer App Engine runtimes .
d
for days, h
for hours, m
for
minutes, and s
for seconds. For example, "4d 5h"
sets cache expiration to 4 days and 5 hours after
the file is first requested. If omitted, the application's default_expiration
is used. See Cache
expiration
for more details.http_headers
Optional. You can set HTTP
headers
for responses of your static file or directory
handlers. If you need to set HTTP headers
in your script
handlers, you should instead do that in your app's
code. For information about which response headers influence caching,
see Caching
static content
.
handlers : - url : /images static_dir : static/images http_headers : X-Foo-Header : foo X-Bar-Header : bar value vary : Accept-Encoding # ...
CORS Support
One important use of this feature is to support cross-origin resource sharing (CORS), such as accessing files hosted by another App Engine app.
For example, you could have a game app mygame.uc.r.appspot.com
that accesses assets hosted by myassets.uc.r.appspot.com
.
However, if mygame
attempts to make a JavaScript XMLHttpRequest
to myassets
, it will not
succeed unless the handler for myassets
returns an Access-Control-Allow-Origin:
response header containing
the value http://mygame.uc.r.appspot.com
.
Here is how you would make your static file handler return that required response header value:
handlers : - url : /images static_dir : static/images http_headers : Access-Control-Allow-Origin : https://mygame.uc.r.appspot.com # ...
Note: if you wanted to allow everyone to access your assets, you could
use the wildcard '*'
, instead of https://mygame.uc.r.appspot.com
.
mime_type
Optional. If specified, all files served by this handler will be served using the specified MIME type. If not specified, the MIME type for a file will be derived from the file's filename extension. If the same file is uploaded with multiple extensions, the resulting extension can depend on the order in which the uploads occurred.
For more information about the possible MIME media types, see the IANA MIME Media Types website
redirect_http_response_code
Optional. redirect_http_response_code
is used with the secure
setting to set the HTTP response code returned
when performing a redirect required by how the secure
setting is configured. redirect_http_response_code
element has the following
possible values:
-
301 - Moved Permanently response code.
-
302 - Found response code.
-
303 - See Other response code.
-
307 - Temporary Redirect response code.
handlers : - url : /youraccount/.* script : accounts.app login : required secure : always redirect_http_response_code : 301
When a user's request is redirected, the HTTP status code will be set
to the value of the redirect_http_response_code
parameter. If the parameter is not present, 302 will be returned.
script
Optional. Specifies the path to the script from the application root directory:
handlers : # The root URL (/) is handled by the WSGI application named # "app" in home.py. No other URLs match this pattern. - url : / script : home.app # The URL /index.html is also handled by the home.py script. - url : /index\.html script : home.app # A regular expression can map parts of the URL to the # path of the script. - url : /browse/(books|videos|tools) script : \1.catalog.app # All other URLs use the WSGI application named in "app" # in not_found.py. - url : /.* script : not_found.app
A script:
directive must be a python import path, for
example, package.module.app
that points to a WSGI
application. The last component of a script:
directive
using a Python modulepath is the name of a global
variable in the module: that variable must be a WSGI app, and is
usually called app
by convention.
Note: just like for a Python import
statement, each
subdirectory that is a package must contain a file named __init__.py
.
In newer App Engine runtimes, the the behavior of this field has changed .
secure
secure
setting,
including script handlers and
static file handlers. The secure
element has the following
possible values: -
optional - Both HTTP and HTTPS requests with URLs that match the handler
succeed without redirects. The application can examine the request
to determine which protocol was used, and respond accordingly. This
is the default when
secureis not provided for a handler. -
never - Requests for a URL that match this handler that use HTTPS are automatically redirected to the HTTP equivalent URL. When a user's HTTPS request is redirected to be an HTTP request, the query parameters are removed from the request. This prevents a user from accidentally submitting query data over a non-secure connection that was intended for a secure connection.
-
always - Requests for a URL that match this handler that do not use HTTPS are automatically redirected to the HTTPS URL with the same path. Query parameters are preserved for the redirect.
handlers : - url : /youraccount/.* script : accounts.app login : required secure : always
The development web server does not support HTTPS connections. It
ignores the secure
parameter, so paths intended for use
with HTTPS can be tested using regular HTTP connections to the
development web server.
To target a specific version of your app
using the REGION_ID
.r.appspot.com
domain, you replace the periods that would usually separate the
subdomain components of the URL with the string " -dot-
",
for example:
https:// VERSION_ID
-dot-default-dot- PROJECT_ID
. REGION_ID
.r.appspot.com
To use custom domains with HTTPS, you must first activate and configure SSL certificates for that domain .
Google Accounts sign-in and sign-out are always performed using a secure connection, unrelated to how the application's URLs are configured.
Optional. The path to the directory containing the static files, from
the application root directory. Everything after the end of the
matched url
pattern is appended to static_dir
to form the full path to the requested file.
Each file in the static directory is served using the MIME type that
corresponds with its filename extension unless overridden by the
directory's mime_type
setting. All of the files in the
given directory are uploaded as static files, and
none of them can be run as scripts.
All files in this directory are uploaded with your app as static
files. App Engine stores and serves static files separately
from your app's files. Static files are not available in the app's
file system by default. This can be changed by setting the application_readable
option to true.
handlers : # All URLs beginning with /stylesheets are treated as paths to # static files in the stylesheets/ directory. - url : /stylesheets static_dir : stylesheets # ...
static_files
Optional. A static file pattern handler associates a URL pattern with
paths to static files uploaded with the application. The URL pattern
regular expression can define regular expression groupings to be used
in the construction of the file path. You can use this instead of static_dir
to map to specific files in a directory
structure without mapping the entire directory.
handlers : # All URLs ending in .gif .png or .jpg are treated as paths to # static files in the static/ directory. The URL pattern is a # regular expression, with a grouping that is inserted into the # path to the file. - url : /(.*\.(gif|png|jpg))$ static_files : static/\1 upload : static/.*\.(gif|png|jpg)$ # ...
App Engine stores and serves static files separately
from application files. Static files are not available in the
application's file system by default. This can be changed by setting
the application_readable
option to true.
Static files cannot be the same as application code files. If a static file path matches a path to a script used in a dynamic handler, the script will not be available to the dynamic handler.
upload
Optional. A regular expression that matches the file paths for all
files that will be referenced by this handler. This is necessary
because the handler cannot determine which files in your application
directory correspond with the given url
and static_files
patterns. Static files are uploaded and
handled separately from application files. The example
above might use the following upload
pattern: archives/(.*)/items/(.*)
url
Required element under handlers
. The URL pattern, as a
regular expression. The expression can contain groupings that can be
referred to in the file path to the script with regular expression
back-references. For example, /profile/(.*)/(.*)
would match the URL /profile/edit/manager
and use edit
and manager
as the first and second
groupings.
The URL pattern has some differences in behavior when used with the following elements:
-
static_dir - Uses a URL prefix. The regular express pattern should not contain
groupings when used with the
static_direlement. All URLs that begin with this prefix are handled by this handler, using the portion of the URL after the prefix as part of the file path. -
static_files - A static file pattern handler associates a URL pattern with paths to
static files uploaded with the application. The URL pattern regular
expression can define regular expression groupings to be used in the
construction of the file path. You can use this instead of
static_dirto map to specific files in a directory structure without mapping the entire directory.
Scaling elements
The elements in following table configure how your application scales. To learn more about how App Engine apps scale, see Scaling types .
automatic_scaling
Optional. Applicable only for applications that use an instance class of F1 or higher.
Specify this element to change default settings for automatic scaling, such as setting minimum and maximum levels for number of instances, latency, and concurrent connections for a service.
This element can contain the following elements:
-
max_instances - Optional. Specify a value between 0 and 2147483647, where zero
disables the setting.
This parameter specifies the maximum number of instances for App Engine to create for this module version. This is useful to limit the costs of a module.
-
min_instances -
Optional. The minimum number of instances for App Engine to
create for this module version. These instances serve traffic when
requests arrive, and continue to serve traffic even when
additional instances are started up as required to handle traffic.
Specify a value from 0 to 1000. You can set the parameter to the value 0 to allow scaling to 0 instances to lower costs when no requests are being served. Note that you are charged for the number of instances specified whether they are receiving traffic or not.
-
max_idle_instances -
Optional. The maximum number of idle instances that App Engine should maintain for this version. Specify a value from 1 to 1000. If not specified, the default value is
automatic, which means App Engine will manage the number of idle instances. Keep the following in mind:- 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 can temporarily exceed your specified maximum. However, you will not be charged for more instances than the maximum number you've specified.
-
min_idle_instances -
Optional: The number of additional instances to be kept running and ready to serve traffic for this version.
App Engine calculates the number of instances necessary to serve your current application traffic based on scaling settings such as
target_cpu_utilizationandtarget_throughput_utilization. Settingmin_idle_instancesspecifies the number of instances to run in addition to this calculated number. For example, if App Engine calculates that 5 instances are necessary to serve traffic, andmin_idle_instancesis set to 2, App Engine will run 7 instances (5, calculated based on traffic, plus 2 additional permin_idle_instances).Note that you are charged for the number of instances specified whether they are receiving traffic or not. Keep the following in mind:
- A low minimum helps keep your running costs down during idle periods, but means that fewer instances might 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 the minimum number of instances running to serve incoming requests. You are charged for the number of instances specified, whether or not they are handling requests.
If you set a minimum number of idle instances, pending latency will have less effect on your application's performance.
-
target_cpu_utilization - Optional. Specify a value between 0.5 and 0.95. The default is
0.6.This parameter specifies the CPU usage threshold at which new instances will be started to handle traffic, enabling you to balance between performance and cost, with lower values increasing performance and increasing cost, and higher values decreasing performance but also decreasing cost. For example, a value of 0.7 means that new instances will be started after CPU usage reaches 70 percent.
-
target_throughput_utilization - Optional. Specify a value from 0.5 to 0.95. The default is
0.6.Used with
max_concurrent_requeststo specify when a new instance is started due to concurrent requests. When the number of concurrent requests reaches a value equal tomax_concurrent_requeststimestarget_throughput_utilization, the scheduler tries to start a new instance. -
max_concurrent_requests -
Optional. The number of concurrent requests an automatic scaling instance can accept before the scheduler spawns a new instance (Default: 10, Maximum: 1000).
Used with
target_throughput_utilizationto specify when a new instance is started due to concurrent requests. When the number of concurrent requests reaches a value equal tomax_concurrent_requeststimestarget_throughput_utilization, the scheduler tries to start a new instance.We recommend you do not set
max_concurrent_requeststo less than 10 unless you need single threading. A value of less than 10 is likely to result in more instances being created than you need for a threadsafe app, and that may lead to unnecessary cost.If this setting is too high, you might experience increased API latency. Note that the scheduler might spawn a new instance before the actual maximum number of requests is reached.
-
max_pending_latency -
The maximum amount of time that App Engine should allow a request to wait in the pending queue before starting additional instances to handle requests so that pending latency is reduced. When this threshold is reached, it is a signal to scale up, and results in an increase in the number of instances. If not specified, the default value is
automatic. This means requests can remain in the pending queue for up to 10s, the maximum pending request time limit , before new instance starts are triggered.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 might 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.
-
min_pending_latency -
An optional element you can set to specify the minimum amount of time that App Engine should allow a request to wait in the pending queue before starting a new instance to handle it. Specifying a value can lower running costs but increase the time users must wait for their requests to be served.
For free apps, the default value is
500ms. For paid apps, the default value is0.This element works together with the
max_pending_latencyelement to determine when App Engine creates new instances. If pending requests are in the queue:- Less than the
min_pending_latencyyou specify, App Engine will not create new instances. - More than
max_pending_latency, App Engine will try to create a new instance. - Between the time specified by
min_pending_latencyandmax_pending_latency, App Engine will try to reuse an existing instance. If no instances are able to process the request beforemax_pending_latency, App Engine will create a new instance.
- Less than the
automatic_scaling : target_cpu_utilization : 0.65 min_instances : 5 max_instances : 100 min_pending_latency : 30ms max_pending_latency : automatic max_concurrent_requests : 50
basic_scaling
Applications that use an instance
class
of B1 or higher must specify either this element or manual_scaling
.
This element enables basic scaling of instance classes B1 and higher, can contain the following elements:
-
max_instances - Required. The maximum number of instances for App Engine to create for this service version. This is useful to limit the costs of a service.
-
idle_timeout - Optional. The instance will be shut down this amount of time after
receiving its last request. The default is 5 minutes
(
5m).
basic_scaling : max_instances : 11 idle_timeout : 10m
manual_scaling
Applications that use an instance
class
of B1 or higher must specify either this element or basic_scaling
.
This element enables manual scaling of instance classes B1 and higher, and can contain the following element:
-
instances - The number of instances to assign to the service at the start.
manual_scaling : instances : 5
