サーバーのスケーラビリティ-HTML 5 WebソケットとComet
Caplinなどの多くのComet実装は、サーバーのスケーラブルなソリューションを提供します。
以下は Caplin サイトからの統計の1つです。
Caplin liberatorの単一インスタンスは、最大100,000のクライアントをサポートでき、各クライアントは1秒あたり1メッセージを受信し、平均待ち時間は7ミリ秒未満です
これは、どのWebサーバー上のHTML5 WebSocketと比べてどうですか？誰かが私にHTML 5 WebSocketsの統計情報を教えてもらえますか？
開示-私はCaplinで働いています。
このページには少し間違った情報がありますので、わかりやすく説明したいと思います。
私たちが話している方法を3つのキャンプに分割できると思います。
- コメットHTTPポーリング-ロングポーリングを含む
- コメットHTTPストリーミング-サーバーからクライアントへのメッセージは、初期セットアップ後にHTTPヘッダーオーバーヘッドのない単一の永続的なソケットを使用します
- コメットWebSocket-単一の双方向ソケット
コメットは単なるパラダイムなので、私はそれらをすべてコメットと見なしていますが、WebSocketが登場して以来、一部の人々はそれをコメットとは異なる、またはコメットに取って代わるように扱いたいと思っています。そうすれば、WebSocketだけに依存することはできません。
パフォーマンスに関する限り、ほとんどのベンチマークはサーバーからクライアントへのメッセージ（ユーザー数、1秒あたりのメッセージ数、およびそれらのメッセージの待ち時間）に集中しています。このシナリオでは、HTTPストリーミングとWebSocketの間に基本的な違いはありません。どちらも、ヘッダーやオーバーヘッドがほとんどないかまったくないオープンソケットにメッセージを書き込みます。
メッセージの頻度が低い場合、ポーリングを長くすると、待ち時間が長くなります。ただし、2つのメッセージ（サーバーからクライアント）が連続している場合、2番目のメッセージは、最初のメッセージの受信後に新しい要求が行われるまでクライアントに到着しません。
誰かがHTTPキープアライブに触れたと思います。これにより、明らかにロングポーリングが改善されます。まだラウンドトリップとヘッダーのオーバーヘッドはありますが、常にソケットが作成されるわけではありません。
WebSocketは、クライアントからサーバーへのメッセージが多いシナリオでHTTPストリーミングを改善する必要があります。これらのシナリオを現実の世界に関連付けると、誰もが理解できる「大量のメッセージを多数のクライアントに送信する」という単純な理解に比べて、わずかに恣意的な設定が作成されます。たとえば、取引アプリケーションでは、取引を実行するユーザー（つまり、クライアントからサーバーへのメッセージ）を含めるシナリオを作成するのは簡単ですが、基本的なサーバーからクライアントへのシナリオよりも少し意味がありません。トレーダーは100トレード/秒を実行しようとしないため、「10000ユーザーが100メッセージ/秒を受信し、同時にクライアントメッセージを5分ごとに送信する」という結果になります。クライアントからサーバーへのメッセージのより興味深い部分は待ち時間です。必要なメッセージの数は通常、サーバーからクライアントへのメッセージに比べて重要ではないためです。
上記の別のポイント、64kクライアントについて、サーバーで64kを超えるソケットをサポートするために巧妙なことをする必要はありません-数のファイル記述子などを構成する以外は。単一のクライアントマシンから64k接続を行う場合、それぞれにポート番号が必要なため、まったく異なります。サーバー側では問題ありませんが、リッスン側であり、64kソケットを超えると問題ありません。
理論的には、WebSocketはHTTPよりもはるかに優れたスケーリングが可能ですが、いくつかの注意事項と、それらの注意事項に対処するためのいくつかの方法もあります。
HTTPとWebSocketのハンドシェイクヘッダー処理の複雑さはほぼ同じです。 HTTP（および最初のWebSocket）ハンドシェイクは、簡単に1Kを超えるデータになる可能性があります（Cookieなどにより）。重要な違いは、HTTPハンドシェイクがeveryメッセージごとに再度発生することです。 WebSocket接続が確立されると、メッセージあたりのオーバーヘッドは2〜14バイトになります。
@David Titarencoの回答に掲載された優れたJettyベンチマークリンク（ 1 、 2 ）は、WebSocketがの順序よりも簡単に達成できることを示していますコメットと比較した場合、レイテンシが大幅に向上します。
WebSocketsとHTTPのスケーリングの詳細については、 この回答 を参照してください。
注意事項：
WebSocket接続は、存続期間が短いHTTP接続とは異なり、存続期間が長くなります。これによりオーバーヘッドが大幅に削減されます（すべての要求/応答に対してソケットの作成と管理は不要）。ただし、サーバーを64kの個別の同時クライアントホストより上にスケーリングするには、同じサーバーで複数のIPアドレスなどのトリックを使用する必要があります。
Web仲介者のセキュリティ上の問題により、ブラウザーからサーバーへのWebSocketメッセージにはすべてのペイロードデータXOR Masked。これにより、サーバーにCPU使用率が追加され、メッセージをデコードします。ただし、XORは、ほとんどのCPUアーキテクチャで最も効率的な操作の1つであり、多くの場合、ハードウェアアシストが利用可能です。サーバーからブラウザーへのメッセージはマスクされません。また、WebSocketの多くの使用は、ブラウザーからサーバーに送信される大量のデータを必要としないため、これは大きな問題ではありません。
（平均）ペイロードサイズがどれほど大きいかわからないので、それがどのように比較されるかを知るのは困難です。内部的には（サーバーの実装方法と同様に）、HTTPストリーミングとWebソケットはほぼ同じです。ただし、初期のハンドシェイク（HTTPを使用すると明らかに複雑になる）は除きます。
C（ala Caplin）で独自のWebSocketサーバーを作成した場合は、それほど困難なくこれらの数値に到達できます。ほとんどのWebSocket実装は、Jettyなどの既存のサーバーパッケージを介して行われるため、比較は実際には公平ではありません。
いくつかのベンチマーク：
http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/
http://webtide.intalio.com/2011/08/prelim-cometd-websocket-benchmarks/
ただし、libevやlibeventなどのCイベントlibベンチマークを見ると、数値は非常にセクシーに見えます。
http://libev.schmorp.de/bench.html
他の場所で説明されているように、更新レートが高いときにレイテンシが発生する可能性があるポーリングの形式を無視すると、JavaScriptストリーミングの最も一般的な3つの手法は次のとおりです。
- WebSocket
- Comet XHR/XDRストリーミング
- コメットフォーエバーIFrame
WebSocketはこれまでで最もクリーンなソリューションですが、ブラウザやネットワークインフラストラクチャがWebSocketをサポートしていないという問題がまだ残っています。より早く信頼できる方が良いでしょう。
XHR/XDRとForever IFrameはどちらもサーバーからクライアントにデータをプッシュするのに適していますが、すべてのブラウザーで一貫して機能するようにさまざまなハックを行う必要があります。私の経験では、これらのCometアプローチは、WebSocketよりも常にわずかに遅くなります。これを機能させるために必要なクライアント側のJavaScriptコードがはるかに多いためです。ただし、サーバーの観点から見ると、データの送信は同じ速度で行われます。
さらにいくつか WebSocketベンチマークグラフ ですが、今回は私たちの製品 my-Channels Nirvana です。
マルチキャストデータとバイナリデータのグラフをスキップして、ページの最後のグラフに移動します（JavaScript高更新率）
要約-結果は、Nirvana WebSocketが50のイベント/秒を2,500kユーザーに800マイクロ秒のレイテンシで配信することを示しています。ユーザー数が5,000の場合（合計でストリーミングされる250kイベント/秒）、待機時間は2ミリ秒です。