27

非常に負荷の高い Web サイトがあり、テスト アプリを非表示の iframe の下に置いて、ターゲット フレームワークがユース ケースに適していることを確認しています。最初にSignalRテストアプリを試し、次に同じサーバー構成でPokeinを試しました。現在、Flash リモーティング ソリューションを使用していますが、まもなく変更する予定です。

Web サイトの負荷が高い状態でクライアントの同時更新を処理するために、SignalR ベースのテスト アプリケーションを作成するのに時間を費やしました。シナリオ(一部のクライアントがメッセージを要求する)ではうまく機能していました.接続されているクライアントのほとんどが同時にメッセージを要求すると、劇的に失敗しました(iframe呼び出しから削除する必要がありました)..私は私のサーバー構成が問題だと思っていましたが、同じシナリオは他の有料ソリューション Pokein でも問題なく動作します。

私が忘れるトリックはありますか?

2012 年 2 月 10 日更新: PokeIn をソリューションに実装することにしましたが、Github で最新の SignalR コードを試しました (他の人にとっては役立つかもしれません)。結果は同じです。

2012 年 3 月 13 日更新: シナリオ: (もう一度) - 接続されている数千のクライアントに一定の間隔 (1 秒) でメッセージを送信してみてください。テストして結果を確認するのは難しくありません。このタイプの非常に一般的な使用法についてライブラリにストレスを与えているのは私だけだと思います。

詳細 (再現方法 - Github の 0.5 でテスト) - Server 2008 R2 32GB DDR3, i7-2600 3.4Ghz, 2x256 GB Crucial M4 - ASP.NET 3.5

  • シングルページアプリ。サーバーからのクライアント側の時刻を毎秒更新します
  • このページは、実際の負荷テストを行うために、いくつかの Web サイトによって読み込まれる非表示の iframe に埋め込まれています。

  • 問題

    • ある時点 (約 800 ユーザー) でシステムがロックされ、ほとんどのクライアントがサーバーから更新された時間を取得できません。

    • システムがロックされると、その 1 つのアプリ ページが応答を停止します

また、間隔を 5 秒に増やしてみました。今回はシステムの応答性が向上しましたが (約 950 ユーザー)、結果は同じでした。これを .NET 2 および .NET 4 アプリケーション プールで試しました。

これらの詳細で十分であることを願っています。このテストを繰り返すことは私にとって非常に簡単であり、空き時間を見つけたらすぐに、将来のバージョンでテストを繰り返します.

4

0 に答える 0