Google App Engineマニュアルスケーリングインスタンスのログに/ _ah/startリクエストが散在しています

Question

Google App Engineモジュール/サービスから静的なウェブサイトを提供しています。待ち時間を改善するために、2つのB4インスタンスを手動でスケーリングするように構成しました。これは一般的にはうまくいくが、そのモジュール/サービスのログは/ _ah/start要求によって事実上散らばっている。私が理解しているように、これは起動時に最初にインスタンスに送信されるウォームアップ要求です。ただし、手動でスケーリングし、メモリ常駐インスタンスの私たちのセットアップで

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' 

、私は理解していない。この要求は、多くの場合、すべてのことを行われている理由：ここに私のapp.yamlをです。実際、私は、提供されているすべてのWebセッションに対して1つの/ _ah/start要求があると思っています。これは非常に奇妙です。誰も同じ経験をしましたか？ Startup

から

Answer 1

：

各モジュールインスタンスは は/ _ah /開始する空のHTTP GET要求で開始要求に応答して作成されます。 App Engineはこの リクエストを送信してインスタンスを作成します。ユーザーは/ _ah/startに リクエストを送信できません。手動スケジューリングインスタンスと基本スケーリングインスタンスは、別の要求を処理する前に開始要求に を応答しなければなりません。スタート 要求は2つの目的のために使用することができます。

• それが基本的な追加のトラフィック

マニュアルを受ける前に、インスタンスを初期化するには、さらに要求

を受け入れずに、無期限に実行するプログラムを開始するには起動時に自動的にインスタンスのスケーリングが行われる があります。手動スケーリングインスタンスを起動すると、App Engine は即座に/ _ah/startリクエストを各インスタンスに送信します。 基本スケーリングモジュールのインスタンスを起動すると、App Engineは がトラフィックを受け入れることを許可しますが、最初のユーザーリクエストを受信するまで/ _ah/startリクエストはインスタンス に送信されません。複数の基本スケーリング インスタンスは、増加した トラフィックを処理するために、必要に応じて起動されます。インスタンスを自動的にスケーリングすると、/ _ah/start 要求は受信されません。

インスタンスがHTTP ステータスコード200-299または404で/ _ah/start要求に応答すると、 が正常に開始されたとみなされ、追加要求を処理できます。それ以外の場合は、App Engine がインスタンスを終了します。手動スケーリングインスタンスはすぐに から再開され、基本スケーリングインスタンスは がトラフィックを処理するために必要な場合にのみ再開されます。

手動スケーリングを選んだ、アプリは（インスタンスを再起動した後）要求を繰り返してから、GAEを防ぐために、特定の方法でそれに答える必要がありますので、だから、そのような要求を取得することが普通です。

アクティブなアプリコードが実際にはなく、静的なコンテンツはすべて、/_ah/start要求が行われていないデフォルト（自動）スケーリングに安全に戻ることができます。この変更は応答時間には何の影響も与えません。静的コンテンツは、実行中のアプリケーション（インスタンスの設定が問題となる場所）に触れずに、CDNのようにGAEインフラストラクチャによって直接提供されます。同様の理由から、インスタンスクラスを最も安いクラスにドロップすることもできます：B1。

更新：

実はapp.yamlコンテンツは、あなたのアプリにいくつかの活性のコードを示しん：あなたは、対応するsite_main.pyファイルを持っている必要があり

url: /proxy/vimeo 
    script: site_main.app 

います。そのコードのパフォーマンスが現在のスケーリング/インスタンスの設定を維持する必要がある場合は、/_ah/startリクエストのハンドラをそのファイルに追加し、GAEが成功と解釈するコードの1つを返信します。