WebSocket でいくつかのテストを実行しています。
テストには、Alchemy-Websockets .NET ベースのサーバーを使用しました。
Web アプリケーションはいくつかのウィンドウを開き、さまざまなサービスやシステムを監視していました。
リアルタイムの更新を反映するために、サーバーがクライアントに多くのイベントを送信する必要がある高負荷の状況に特に興味があります。GUI を完全にレスポンシブにして、リアルタイムのユーザー エクスペリエンスでグリッドとグラフにデータを表示したいと考えています。
メイン ウィンドウ スレッドで WebSocket を作成し、着信メッセージごとに、グリッドが表示に使用している配列 (SlickGrid) にエントリを追加しました。GUI を正常に動作させるために、グリッドの更新をレンダリングするために 20 ミリ秒の setInterval を追加しました。すべてが正常に動作し、非常に高速です。
問題は、WebSocket をワーカー スレッドに移動することが望ましいか、推奨されるかです。スレッドで I/O を処理することを推奨するユース ケースで見たワーカー スレッドについて読んでいます。
これは、ブロックしている場合にのみ意味があると思います。
私の知る限り、WebSocket は非同期であり、ブロックしません。ブラウザによって内部的にスレッドに実装されていることをどこかで読みましたが、これは理にかなっています。
WebSocket をワーカーに移動して、ワーカーがデータをメイン ウィンドウに移動する前にバッファリングまたは集約できるようにすることを検討しています。イベント レートが高い場合は、次のアプローチが考えられます。
- メイン ウィンドウ スレッドは定期的に (約 20 ミリ秒ごとに) ワーカーをポーリングし、必要なデータを取得します。
- ワーカーは、より大きなデータのチャンクを定期的に送信します。
- Webソケットがデータを受信するたびに、それをメインスレッドに送信しますが、同じ固有の問題が発生すると思います。(ここでテストを開始し、ワーカー スレッドで無限ループを作成し、すべてのステップでメイン スレッドにメッセージを送信し、GUI がフリーズしました)。
WebSocket をメイン スレッドに残すことも理想的ではありません。サーバーからの負荷が高い場合、GUI は WebSocket 受信メッセージ イベントを優先しません。
ワーカー スレッドでデータを収集すると、ワーカーがバッファリングしているため、高負荷時にリアルタイムの更新を見逃す可能性があります。
ワーカー スレッドのもう 1 つの問題は、データの重複であると思われます。これは、新しい転送可能オブジェクトによって解決できますが、すべてのブラウザーでどの程度サポートされているかはまだわかりません。
メイン ウィンドウで WebSocket をホストしないのはなぜですか?
では、ベストプラクティスは何ですか?