CODEWITHSUNDEEP
google-app-enginegoogle-app-engine-python
Soeren
Soeren

Reputation: 711

Google App Engine manual scaling instance log littered with /_ah/start requests

I am serving a static website from a Google App Engine module/service. In order to improve latency, I have configured manual scaling with two B4 instances constantly up. While this works generally OK, the logs of that module/service is virtually littered with /_ah/start requests. As I understand, this is a warmup request that is initially sent to an instance when it launches. Here is my app.yaml:

runtime: python27
api_version: 1
threadsafe: true
module: site
default_expiration: "2d"
instance_class: B4
manual_scaling:
    instances: 2

handlers:
    -
        url: /proxy/vimeo
        script: site_main.app
        secure: always
    -
        url: /auth/vimeo\.html
        static_files: static/vimeo.html
        upload: static/vimeo.html
        secure: always
    -
        url: '/[^\.]*$'
        static_files: static/index.html
        upload: static/index.html
        secure: always
    -
        url: /assets/(.*)$
        static_files: static/assets/\1
        upload: static/.*
        secure: always
        expiration: "31d"
    -
        url: '/*'
        static_dir: static/
        secure: always
skip_files:
    - '^(.*/)?#.*#$'
    - '^(.*/)?.*~$'
    - '^(.*/)?.*\.py[co]$'
    - '^(.*/)?\..*$'
    - '^(.*/)?.*\.gz'

With our setup of manually scaled, memory-resident instances though, I do not understand why this request is being made all that often. In fact, I like to think that there is one /_ah/start request for every web session being served, which is extremely odd. Has anyone made the same experience?

Upvotes: 0

Views: 973

Answers (1)

Dan Cornilescu
Dan Cornilescu

Reputation: 39824

From Startup:

Each module instance is created in response to a start request, which is an empty HTTP GET request to /_ah/start. App Engine sends this request to bring an instance into existence; users cannot send a request to /_ah/start. Manual and basic scaling instances must respond to the start request before they can handle another request. The start request can be used for two purposes:

  • To start a program that runs indefinitely, without accepting further requests
  • To initialize an instance before it receives additional traffic

Manual, basic, and automatically scaling instances startup differently. When you start a manual scaling instance, App Engine immediately sends a /_ah/start request to each instance. When you start an instance of a basic scaling module, App Engine allows it to accept traffic, but the /_ah/start request is not sent to an instance until it receives its first user request. Multiple basic scaling instances are only started as necessary, in order to handle increased traffic. Automatically scaling instances do not receive any /_ah/start request.

When an instance responds to the /_ah/start request with an HTTP status code of 200–299 or 404, it is considered to have successfully started and can handle additional requests. Otherwise, App Engine terminates the instance. Manual scaling instances are restarted immediately, while basic scaling instances are restarted only when needed for serving traffic.

So it's normal to get such requests since you chose manual scaling and your app should reply to it in a certain manner to prevent GAE from repeating the request (after restarting your instance).

But since you don't really have any active app code and all you serve is static content you can safely return to the default (automatic) scaling for which no /_ah/start requests are made. The change should have no impact whatsoever on the response time - static content is served by GAE infra directly, like a CDN, without even touching your running app (where the instance configs matter). For that same reason you can also drop the instance class to the cheapest one: B1.

Update:

Actually the app.yaml content does indicate some active code in your app:

    url: /proxy/vimeo
    script: site_main.app

For which you should have a corresponding site_main.py file. If the performance of that code requires you to keep the current scaling/instance configs just add to that file a handler for the /_ah/start requests, replying with one of the codes that GAE interprets as success - that should put an end to the log littering.

Upvotes: 1

Related Questions