2

アプリに対して負荷テストを実行すると、非常に一貫した応答時間が表示されます。GAE に一定レベルの負荷がかかると、平均応答時間はどんどん短くなります。しかし、1 秒あたりのリクエスト数がはるかに少ない他のアプリでも同じ一貫性を保ちたいと考えています。それらでは、1 秒あたり最大 3 リクエスト以上をサポートする必要はありません。

ドキュメントを読むと、最小アイドル インスタンスの数を増やすと、より一貫した応答時間が得られるはずだと思います。ただし、その場合でも、GAE のスケジューラーがより多くのインスタンスが必要であると判断するたびに、クライアントの応答時間が長くなります。ユーザーがこれらの最初の遅いリクエストを表示しないセットアップを探しています。

アイドル状態のインスタンスの最小数を 1 に増やした場合、GAE が 1 つの常駐インスタンスのみを使用するようにします。負荷が増加すると、新しい (動的) インスタンスを起動してウォームアップする必要があります。それらがウォームアップされて初めて、GAE はそれらに要求を送信する必要があります。しかし、応答時間から判断すると、クライアント要求が起動されたときに動的インスタンスに到着するように見えます。その結果、これらのリクエストには長い時間がかかります (最大 30 秒)。

  • これは、ウォームアップ コードが不完全な場合に発生する可能性がありますか?
  • まだウォームアップされていないコード パスが含まれているため、動的インスタンスの最初の呼び出しが非常に遅くなる可能性はありますか?

負荷テスト中や十分な人数がアプリを使用している場合、この問題は発生しません。しかし、私のテスト環境は、朝など、誰もアプリを使用していないときは、クライアントが実質的に使用できません。

ありがとう！

4

1 に答える 1

1

いくつかの一般的な考え:

  • インスタンスの起動時間は 30 秒と非常に長いようです。多くの初期化 (データベース ヒットを含む) を行い、約 5 秒のオーバーヘッドがあります。
  • ウォームアップ リクエストは保証されません。すべてのインスタンスがビジーであり、ビジー状態のインスタンスでキューに入れるのではなく、新しいインスタンスを開始した方がリクエストへの応答が速くなるとスケジューラが判断した場合、ウォームアップ リクエストで時間を無駄にすることなくそうします。
  • これはコールド コード パスの問題ではないと思います (ただし、Java のホットスポットの詳細はわかりません)。おそらく、最初にいっぱいになる必要がある (mem-) キャッシュです。
  • 「不完全なウォームアップ コード」の意味がわかりません。/_ah/warmup へのリクエストがないかログを確認してください。もしあれば、ウォームアップ リクエストが有効になっており、機能しています。
  • 1 インスタンス マークを超えてアイドル インスタンスの量を増やしても、おそらくここでは役に立ちません。

悲しいことに、それを回避するための一般的なトリックはありませんが、試してみることができます

  • 初期化コードを延期する (インスタンスの起動オーバーヘッドの絶対的に必要な最小値のみを実行する)
  • (mem-) キャッシュをホットに保つバックエンドを開始する

コストを気にしない場合 (そして、少量のアプリケーションに自動スケーリングを必要としない場合) は、すべてのリクエストを常時稼働のバックエンドで処理することもできます。

于 2013-02-27T16:23:20.903 に答える