Stay organized with collections Save and categorize content based on your preferences.
You can use warmup requests to reduce request and response latency during the time when your app's code is being loaded to a newly created instance.
App Engine frequently needs to load your app's code into a fresh instance. Loading an instance can happen in the following situations:
Loading your app's code to a new instance can result in loading requests. Loading requests can result in increased request latency for your users, but you can avoid this latency using warmup requests. Warmup requests load your app's code into a new instance before any live requests reach that instance.
If warmup requests are enabled for your application, App Engine attempts to detect when your application needs a new instance and initiates a warmup request to initialize a new instance. However, these detection attempts do not work in every case. As a result, you might encounter loading requests, even if warmup requests are enabled in your app. For example, if your app is serving no traffic, the first request to the app will always be a loading request, not a warmup request.
Warmup requests use instance hours like any other request to your App Engine application. In most cases where warmup requests are enabled, you won't notice an increase in instance hours because your application is simply initializing in a warmup request instead of a loading request. Your instance hour usage can increase if you decide to do more work, such as pre-caching during a warmup request. If you set min_idle_instances to greater than 0, you might encounter warmup requests when those instances first start, but they will remain available after that time.
Warmup requests are used by the App Engine scheduler, which controls the auto scaling of instances based on user-supplied configuration. With warmup requests enabled, App Engine issues GET requests to /_ah/warmup. You can implement handlers for this request to perform application-specific tasks, such as pre-caching application data.
The scheduler starts up instances when it determines that more instances are needed. Warmup requests may appear in logs even if they are disabled because the scheduler uses them to start instances.
Note that warmup requests are not guaranteed to be called. In some situations loading requests are sent instead: for example, if the instance is the first one being started up, or if there is a steep ramp-up in traffic. However, there will be a "best effort" attempt to send requests to already warmed-up instances if warmup requests are enabled.
To enable warmup requests, add the warmup element under the inbound_services directive in your app.yaml file, for example:
inbound_services:
- warmup
You can register the script that handles warmup requests in your project's app.yaml file. For example:
inbound_services:
- warmup
handlers:
- url: /_ah/warmup
script: main.py
login: admin
This example registers a handler to listen to warmup requests to the /_ah/warmup request path with the main.py file.
Create a handler that will process the requests that are sent to /_ah/warmup. Your handler should perform any warmup logic that is needed by your app. The following example builds on the previous example:
import webapp2
class MyWarmUpCode(webapp2.RequestHandler):
"""
This class handles the warmup request. You should add any code that you
need to execute in the `get` method, such as populating caches, and ensure
that you return a successful HTTP response.
"""
def get(self):
# Your warmup logic goes here.
# Return a successful response to indicate the logic completed.
self.response.headers['Content-Type'] = 'text/plain'
self.response.write('Warmup successful')
# ...
application = webapp2.WSGIApplication(
[
('/_ah/warmup', MyWarmUpCode),
# Other handlers
# ...
]
)
You might want to store values in an in-memory datastore such as Memcache, giving your app fast, query-less access to data.
For example, if you build and store a list of the current trending articles for your site, you can build that list in the warmup and store it in Memcache. When a user request comes in, App Engine doesn't need to perform any datastore queries and the application can serve the user's request faster.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-08-07 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["Warmup requests reduce latency by loading your app's code into a new instance before live requests arrive, avoiding delays caused by loading requests."],["App Engine uses warmup requests to initialize new instances in various situations, such as during redeployments, increased traffic, or infrastructure maintenance, attempting to detect when a new instance is required."],["Warmup requests are `GET` requests to `/_ah/warmup`, and you can define custom handlers to perform application-specific tasks like pre-caching data."],["Enabling warmup requests involves adding the `warmup` element under `inbound_services` in your `app.yaml` file and creating a handler to process the `/_ah/warmup` requests."],["While warmup requests generally don't significantly increase instance hours, they can offer performance benefits by pre-loading resources and potentially interacting with services such as Memcache."]]],[]]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4