1

最近、Google App Engine でのサービスの負荷が短期間で急激に増加しました。負荷は、約 2 時間で 1 ～ 2 リクエスト/秒から約 10 リクエスト/秒になりました。動的インスタンスの数はかなり急速に拡大しましたが、その過程で「リクエストが長すぎます」というタイムアウト メッセージが多数表示されました。

そのため、次回は、負荷を処理するのに十分なアイドル状態のインスタンスを準備したいと考えています。しかし、問題は、適切な数をどのように判断するかです。今回は、はるかに大きな負荷のバーストが予想されます。実際には何もない状態から、平均 500 要求/秒、おそらく 3000 のピークまで発生します。これは 15 分から 1 時間続くと予想されます。

私の主な目標は、HTTP Post を介して渡された情報が、1 回の書き込みによってデータストアに確実に保存されるようにすることです。

バーストに備えるために私が取った手順は次のとおりです。

  1. 通常 2 つの urlfetch リクエストを生成する分析やその他のレポートを無効にするために、ファスト パスを削除しました。
  2. データストアの書き込みは、遅延ライブラリを介してタスクキューに遅延されます

私が知りたいのは: 1. N リクエスト/秒あたりに必要なアイドル インスタンスの数を計算するためのヒント/洞察。2. タスク キューの最大スループットは 500/秒のようです。これはタスクをプッシュできるレートですか? そうでない場合、上限はありますか? これらはおそらくデータストアへの書き込みにすぎないため、そうではないと思いますが、確認したいと思います。

このフラッシュ モブのすべての情報を保存する自信がない場合の代替案は、強力な Amazon EC2 インスタンスをセットアップし、その上で Web サーバーを実行して、クライアントにこのサーバーにバックアップ リクエストを送信させることです。

4

1 に答える 1

2

アイドル インスタンスは、新しいフロントエンド インスタンスがスピンアップされている場合にのみ使用されることを理解する必要があります。これは、トラフィックが増加したときにのみ使用されることを意味します。トラフィックが安定している場合、それらは使用されません。

インスタンスがスピンアップするのに 20 秒必要で、10 リクエスト/秒の安定したトラフィックを処理でき、トラフィックの増加が 5 リクエスト/秒である場合、不要な場合は 20 * 5 / 10 = 10 のアイドル インスタンスが必要になります。すべてのリクエストがドロップされました。

あなたがすべきことは次のとおりです。

  1. インスタンスのスループット (処理できるリクエストの数) を最大化します。コードを最適化し、非同期データベース操作を使用し、同時リクエストを有効にします。

  2. インスタンスの起動時間を最小限に抑えます。アイドル インスタンスは新しいインスタンスのスピンアップ中に使用され、新しいインスタンスのスピンアップにかかる時間は必要なアイドル インスタンスの数に直接関係するため、これは重要です。Java を使用している場合、これは、クラスパス スキャンを行う重いフレームワーク (Spring など) を取り除くことを意味します。

第 4 に、必要なフロントエンド インスタンスの数は、非常にアプリケーション固有です。しかし、すでにトラフィックが増加しているため、フロントエンド インスタンスが 1 秒あたりに処理できるリクエスト数を知る必要があります。

編集:もう 1 つ、やるべきことが明白です: HTTP キャッシングです。GAE には透過的な HTTP キャッシュCache-Controlがあり、ヘッダー経由で簡単に制御できます。

また、分析がサーバーのパフォーマンスに大きな影響を与える場合は、クライアント側の分析サービス (Google Analytics など) の使用を検討してください。それらはデバイスでも機能します。

于 2013-03-03T19:05:20.940 に答える