5

私は Windows Azure にかなり慣れていないので、調査アプリケーションをホストしたいと考えています。同時に 30.000 ユーザー。

アプリケーションは、クライアントに 1 回送信される 1 つの .aspx ページで構成され、25 の質問をし、最後に与えられた回答のまとめを提供します。ユーザーが回答を入力して「次の質問」ボタンをクリックすると、指定された回答が .ashx ハンドラーを介してサーバーに送信されます。その答えは、次の質問と回答です。ラップアップは、完全なポストバックの後にクライアントに送信されます。回答は、各パーティションが最大 450 人のユーザーを保持できるようにパーティション分割された Azure テーブルに保存されます。

このアプリケーションを実行し続けるためには、いくつの Web ロール インスタンスを開始する必要があるかについて、推定できる人がいるかどうかを尋ねたいと思います。(それを言うのが難しすぎる場合は、5、50、または 500 のインスタンスを開始する可能性が高いですか?)

20 個のスモール インスタンスと 5 個のラージ インスタンスのどちらを使用するのがよいでしょうか?

ご協力いただきありがとうございます！

4

3 に答える 3

5

最も明白な答えは、これを自分でテストして、アプリケーションがどのように機能するかを確認することです。Windows Azure からパフォーマンス カウンターやその他の診断を簡単に取得できます。たとえば、Microsoft SCOM (System Center Operations Manager) を接続して、テスト中に環境を監視できます。Site Hammerは、Windows Azure 用の単純な負荷テスト ツールです (MSDN コード ギャラリーにあります)。

この非常に明白な答えとは別に、いくつかの推測を共有します。負荷のタイプを考えると、特にストレージが既にパーティション分割されている場合は、大きなインスタンスの数が少ないよりも、小さなインスタンスが多い方がよいでしょう。実際に 30,000 人の訪問者が同時に訪れ、質問を読んでから回答を投稿するまでに最大 15 秒の間隔を与える場合、1 秒あたり 2,000 のリクエストを見ていることになります。その負荷を処理するには、10 ノードで十分です。これは単純な見積もりであり、アーキテクチャなどに関する洞察が欠けていることを忘れないでください。これらの種類の負荷には、キャッシュが非常に適しています。各ノードが処理できる負荷が劇的に増加します。

ただし、私ができる最善のアドバイスは、積極的に監視していることを確認することです。追加のインスタンスをスピンアップするのに 30 分もかからないため、環境を監視したり、チョークが始まるたびに通知されるようにしたりすれば、セットアップを簡単にアップグレードできます。20 インスタンスを超えることができるようにするには、カスタマー サポートに連絡する必要があることに注意してください (これは、過剰な支出から保護するためのデフォルトの制限です)。

于 2011-01-15T12:34:35.550 に答える
2

tijmenvdk からの賢明なアドバイスは別として、インスタンス サイズに関する私の意見を追加させてください。一般に、アプリをサポートする最小のサイズを使用してから、増加したトラフィックを処理するためにスケールアウトします。このようにして、スケールダウンしても、最小コンピューティング コストは低く抑えられます。たとえば、ベースラインとして超大規模インスタンスのペアを実行した場合 (アップタイム SLA を取得するには、常に最低 2 つのインスタンスが必要であるため)、コスト フットプリントは 1 時間あたり 0.12 x 8 x 2 = $1.92 から始まります。交通時間。小規模なインスタンスを使用する場合、1 時間あたり 0.12 x 1 x 2 = $0.24 になります。

各 VM は、関連する CPU、メモリ、およびローカル ディスク ストレージとしてサイズ化されるため、アプリが効率的に動作する最小サイズの単位を選択してください。

負荷/パフォーマンス テストの場合は、Loadstormなどのホストされたソリューションも検討する必要があります。

于 2011-01-15T15:23:18.523 に答える
0

要求は実際にはどのくらい同時ですか? 全員がまったく同時にアドレスを入力しますか?

とはいえ、アプリをローカルでプロファイリングすると、Azure での CPU、ネットワーク、およびメモリの使用量を見積もることができます。次に、必要なインスタンスの数ではなく、要件を減らす方法を検討してください。これらのヒントを適用して、再度ローカルでプロファイリングします。

ほとんどのパフォーマンスのヒントには、CPU、メモリ、または帯域幅の使用量の間にトレードオフがあります。アイデアは、それらが均等にスケーリングされるようにすることです。アプリケーションのメモリが不足しているが、CPU とネットワークに負荷がかかっている場合は、使用しないでください。

単一ページの調査の場合、html、css、および js が縮小されていることを確認し、キャッシュ可能であることを確認してください。

可能であればそれらを組み合わせて、実際にスケーラブルにするために、静的ファイル (css、js、画像) を CDN にプッシュします。これにより、Web サーバーが処理しなければならない要求の数が減るため、必要な Web ロールの数が減ります = ネットワークが少なくなります。

ashx はどのように応答を返しますか? つまり、html、xml、または json を送信していますか? 個人的には、必要なネットワーク帯域幅が少なくなり、おそらくサーバー側の処理が少なくなる = メモリとネットワークが少なくなるため、JSON を返すようにします。

非同期 API を使用して azure ストレージにアクセスします (これは IO 完了ポートを使用して iis スレッドを解放し、azure ストレージが戻るまでより多くの要求を処理します = CPU のスケーリングを有効にします)

tijmenvdk は、書き込みにキューを使用することについて既に言及しています。質問のリストは変わりますか？そうでない場合は、それらをキャッシュして、アプリが起動時に 1 回、最終的なラップアップのためにクライアントごとに 1 回だけテーブル ストレージから読み取る必要があるようにします = メモリを犠牲にしてネットワークと CPU を節約します。

これらのヒントはすべて、単一サーバーまたは Web ファーム環境の通常の Web アプリケーションにも同様に適用できます。

私が言いたいのは、測定できないものは改善できないということであり、測定、改善、およびコストはすべて密接に関係しているということです。動的スケーリングはコストを削減しますが、基本的に、アプリケーションが測定されておらず、リソースの使用が最適化されていない場合、必要なインスタンスの数を尋ねることは無意味です。

于 2011-05-26T12:22:30.023 に答える