ASP.NET MVC3 アプリケーションがあります。
私のアプリケーションに多数のユーザー (たとえば 100,000 としましょう) がいる場合、仮説として、すべてのユーザーが互いに話し合っていて、SignalR を使用した場合、100,000 の長いポーリング接続があるでしょうか? これらはある種のサービス拒否を引き起こしますか?
代わりに AJAX HTTP を使用する必要がありますか? または、SignalR は、一定期間アクティビティが見つからない場合に、リソース プールへの接続を解放するほどスマートでしょうか?
チャットと AJAX で、チャットに signalR を使用することが推奨されるのはいつですか?
Windows サーバー上のすべての DoS 攻撃保護をかなり簡単に無効にすることができます。ただし、それで問題が解決するとは限りません。このような場合、100,000 接続には複数のサーバーが必要になります。
最初の制限は、IP アドレスごとに、接続にサービスを提供できる tcp ポートが約 65,000 しかないことです (65,535 ですが、予約済みポートが少ないなどは四捨五入されます)。そのため、複数の IP アドレスを持つ大規模なサーバーが必要になるか (信頼性が低く、システム/アプリの単一障害点になる可能性があります)、何らかのロード バランサーの背後に複数のサーバーが必要になります。
また、ロング ポーリングでは、ロング ポーリング接続が終了し、新しい接続が開始されるたびに、接続の一貫した「ターンオーバー」が見られます。TCP ポートはすぐに再利用されるのではなく、構成可能な最速のTCP 時間待機遅延は 30 秒です。したがって、65,000 の接続でも非現実的です。ポートの再利用のためだけにその半分を使用します。次に、Web ページ、残りの API、またはその他の静的リソースのために、そのサーバーに到着する他の http 要求を考慮に入れる必要があります。次に、データを保存/フォーマットするためにプロセッサ/メモリが実行する必要がある他の処理を考慮に入れます。したがって、おそらくさらに半分に減らします。サーバーあたり 15,000 クライアントが現実的な最大値だと思います。したがって、100,000 人のユーザーの場合、負荷分散されたクラスターでおそらく最低 7 台のサーバーを見ていることになります。
最後に、そのようなマルチサーバー環境では SignalR が機能しないことを確認しました。同様に、AJAX やその他の「頻繁な更新」方法では、利用可能な tcp ポート/ソケットなどの数について、同様の物理的な制限を受けます。そのような http 要求の頻度が高い 1 つのサーバーで 100,000 のクライアントにサービスを提供することはできません。
Amazon EC2 上の複数のサーバーを使用して、 WebSync for ASP.netを使用して、このような大規模な負荷でかなりの量のテストを行いました。私は FrozenMountain で働いており、昨年の仕事の 1 つは、Amazon EC2 クラウドでマルチサーバーの負荷分散テストを行うことでした。Amazon クラウド サービスは、優れたスティッキー ロード バランサーと、テスト用のサーバーの簡単な複製を提供します。「実験室の条件」(他のことをしない専用サーバー) では、7.5 GB RAM のクアッド コア サーバーであるAmazon の「ラージ インスタンス」で 20,000 クライアントを超える可能性があります。
また、最新の Server/IIS/Websync では、各クライアントが Web サーバーへの単一の永続的なソケット接続を維持できるため、ポートのターンオーバーと再利用を減らすのに役立つ WebSockets サポートが得られることも指摘する価値があります。これにより、サーバーあたりのクライアント数が増える可能性があります。したがって、websocket 互換のブラウザー/クライアントの採用率に応じて、7 サーバー クラスターからおそらく 4 ～ 5 サーバーに減らすことができる場合があります。(Web ブラウザー ベースの JavaScript クライアントの採用率は高くありません。iPhone や Android デバイスなどのネイティブ デバイスはすべて WebSocket をサポートしているため、すぐにすべてのメリットを実感できます)。クライアントが Web ソケットをサポートしていない場合、WebSync は WebSocket からロング ポーリングにフェールバックします。