3

App Engineで実行しているシンプルなアプリがありますが、レイテンシーに関して奇妙な問題が発生しています。これはPython2.7アプリであり、読み込み要求には1.5〜10秒かかります（GAEの感じ方によって異なります）。これは現在トラフィックの少ないサイトであるため、以前はGAEはアイドル状態のインスタンスがなく、ほとんどのリクエストがリクエストを読み込んでいたため、最初のページビューでの待機時間が長くなりました。

アイドル状態のインスタンスの最小数を「1」に設定して、これらのまれなページビューがすぐにウォームインスタンスに到達するようにしました。

ただし、1つのインスタンスが未使用のままであっても、GAEが着信要求をロード中のインスタンスにルーティングし、ウォームインスタンスはそのままにしておくケースをいくつか見てきました。

奇妙なスケジュールを示すgaeダッシュボード

どうすればこれを防ぐことができますか？私は確かにこの振る舞いを期待していないので、私は何か間違ったことを理解しているに違いないと感じています。

更新：また、これをさらに理解しにくくしているのは、アプリでスレッドセーフが有効になっていることです。そのため、GAEが慌てて、単一の1つのリクエストに対してインスタンスを起動する理由がよくわかりません。

4

2 に答える 2

1

実際、これは正常な動作だと思います。アイドル状態のインスタンスは、常に利用可能なインスタンスの最小数を保証することになっています（スパイクロードの場合）。

そのため、一部のリクエストが着信し始めると、最初はアイドル状態のインスタンスによって処理されますが、同時にAEスケジューラーは新しいインスタンスの起動を開始して、負荷が突然増加した場合でも常に同じ量のアイドル状態のインスタンスを保証します。つまり、リクエストの処理でビジーになったアイドル状態のインスタンスを「カバー」することです。

詳細については、 「アプリケーションパフォーマンスの調整」ページを参照してください。

于 2012-06-13T20:54:50.640 に答える
0

ああ！これに自分で苦しんでいます。このトピック領域は、いくつかのスレッド（GAEグループおよびSO）で取り上げられています。誰かがトラフィックの少ないサイトの設定をダイヤルインできる場合（請求のオン/オフ）、それは本当のメリットになります。IIRC、私が思うに深いGAEの経験を持つ人は、スケジューラーが非常に少量のアプリではうまく機能しないことを1つのスレッドで指摘しました。また、比較的短い期間内に起動時間が大きく異なることも確認しました。スピンアップが700msかかり、数分後に7000msかかるのを見るのは辛いです。全体として、問題は私にとってそれほどコストではなく、インフラストラクチャリソースの浪費です。テストでは、数分に1回RPCでアプリにpingを実行したにもかかわらず、2つのインスタンスが実行されました。他の5万人の開発者が同様にテストしている場合、それはかなりの無駄に蓄積される可能性があります。

于 2012-06-14T01:26:02.643 に答える