3

シンプルな Web サイトを作成していますが、ユーザーのログイン数が多い (約 25000 の同時ユーザー)。いいえを計算するにはどうすればよいですか。それをサポートするために必要なインスタンスの数は?

4

4 に答える 4

8

負荷テストとパフォーマンス テストは、アプリのパフォーマンス メトリックとインスタンス要件を把握する唯一の方法です。「同時ユーザー」を定義する必要があります。これは、25,000 の同時トランザクションを意味するのでしょうか、それとも単に 25,000 のアクティブ セッションを意味するのでしょうか? 後者の場合、ユーザーはどのくらいの頻度で Web ページにアクセスしますか (ページ間の思考時間など)? 次に、データベース、Azure ストレージ、外部 Web サービス、ロール内通信など、他のすべての可動部分があります。処理パイプラインのこれらすべてのステップがボトルネックになる可能性があります。

SLA を忘れないでください: 25,000 の同時セッション (1 秒あたりのトランザクションではありません) をサポートできると仮定すると、許容できる往復時間はどれくらいですか? 二秒？五？

インスタンス数について考えるときは、計算式で VM サイズも考慮する必要があります。処理パイプラインによっては、たとえば、特定のメモリ要件をサポートするために中規模または大規模の VM が必要になる場合があります。異なる VM サイズをテストすると、まったく異なる結果が得られる場合があります。

反復可能で、エッジ ケース エラーを排除する経験的テストを実行する方法が必要です (たとえば、テストを最低 3 回実行して平均を取得する、明確に定義された方法で系統的に負荷を増やし、その間に結果を観察する)。その負荷の下で一定時間、負荷を追加して安定させるという無秩序な動作を可能にします)。この経験的テストには、よく練られたテスト計画が含まれます (例: フォーム データを含む、特定の使用シナリオでユーザーがヒットするページ)。また、テスト対象のシステムを監視して、特定の負荷がいつ「カーブの曲がり角」 (ボトルネックにぶつかり、パフォーマンスが急激に低下することを意味する) になるかを判断するための適切なツールが必要になります。

最終的な考え: テスト中に負荷生成ツールがボトルネックにならないようにしてください。Visual Studio で Microsoft の負荷テスト ソリューションを使用するか、Loadstormなどのクラウドベースの負荷テスト ソリューションを使用することを検討することをお勧めします(免責事項: Loadstormは昨年負荷/パフォーマンス テストについて私にインタビューしましたが、私は彼らのために働いていません)どんな容量でも）。

編集 2013 年 6 月 21 日TechEd 2013 で発表された Team Foundation Service は、クラウドベースの負荷テストを提供し、プレビューは 6 月 26 日に //build カンファレンスと同時に開始されます。お知らせはこちらです。

于 2010-11-11T08:23:03.663 に答える
2

より多くの情報がなければ、誰もこの質問に答えることはできません...ウェブサイトの構築に使用しているテクノロジー、ページの読み込み時に何が起こるか、どのバックエンド ストレージが使用されているか (もしあれば) など。ログオンするユーザーごとに 100 万桁の円周率を計算するか、ユーザーごとにキャッシュから静的コンテンツを提供することもできます。

最善のアドバイスは、アプリケーションを (クラウドまたは同等のハードウェアで) テストし、そのパフォーマンスを確認することです。

于 2010-11-10T09:42:55.013 に答える
1

それはすべて、アーキテクチャ設計、永続化テクノロジ、および 1 秒あたりに実行している読み取り/書き込み操作の数 (平均/ピーク) によって異なります。

この種のアプリケーションについては、CQRS ベースのアーキテクチャを検討することをお勧めします。クラウド コンピューティング環境に適合し、柔軟なスケーリングが可能です。

于 2010-11-10T11:15:43.183 に答える
0

私は最近 Cloud Summit に参加しましたが、いくつかのケース スタディがありました。印象に残っているのは試験アプリです。2 時間で約 80000 人のユーザーのバースト ロードが発生し、約 300 のインスタンスが起動されます。

負荷プロファイルを知らなければ、より多くの価値を追加することは困難です。ただし、同時実行と継続は同じものではないことに注意してください。「http://twitter.com/#!/spolsky/status/27244766467」というスタック オーバーフローと Digg の大失敗を覚えていますか?

于 2010-12-04T21:51:29.180 に答える