gwt - 約 1 更新/秒の長いポーリングとストリーミング

Question

ストリーミングは実行可能なオプションですか? どちらを選択するかによって、サーバー側でパフォーマンスに違いはありますか? この場合、一方が他方よりも優れていますか?

サーバー側で実行されているTomcatを使用してGWTアプリケーションに取り組んでいます。私のニーズを理解するために、複数の株式の株価を同時に更新することを想像してみてください。

Answer 1

プロセスをクライアント主導にするかサーバー主導にするか? 言い換えると、新しいデータが利用可能になったらすぐにクライアントにプッシュしたいですか、それとも 1 秒に 1 回でなくてもクライアントが適切と判断したときに新しいデータを要求したいですか? クライアントが答えを待つために固執できる可能性はどれくらいですか? イベントは 1 秒に 1 回発生すると予想されますが、クライアントからの要求からサーバーからの応答までにどのくらいの時間がかかりますか? 1 秒よりも長い場合は、イベントをクライアントにプッシュする方向に傾くと思いますが、逆の場合はポーリングで問題ないと思います。応答が間隔よりも長くかかる場合は、クライアントが最後のイベントを受信するまでに新しいイベントの準備ができているため、本質的にストリーミングしていることになります。

クライアントは接続を開いたままにするのではなく、毎回接続を再ネゴシエートする必要があるため、ストリーミング構成ではなく、クライアントベースの (プル) サブスクリプションのサーバー負荷が高くなると思われますが、開いている接続ごとにストリーミング モデルでは、サーバー リソースも必要になります。それは、ネゴシエーション プロセスがどれほど積極的であるかと、開いている接続ごとに必要なメモリ/処理の量との間のトレードオフが何であるかによって異なります。私は専門家ではないので、他の要因があるかもしれません。

更新:この男は、ロング ポーリングとストリーミングのトレードオフについて話しています。HTTP/1.1 では、接続の再ネゴシエーション プロセスは些細なことであり、それほど問題ではないと言っているようです。

Answer 2

それは本当に問題ではありません。接続の再ネゴシエーションのオーバーヘッドは HTTP1.1 では非常に小さいため、パフォーマンスに大きな違いがあることに気付くことはありません。

ロング ポーリングの利点は、互換性と信頼性です。プロキシ、ポート、切断の検出などに問題はありません。

「真の」ストリーミングの利点はオーバーヘッドの削減につながる可能性がありますが、既に述べたように、この利点は想定されているよりもはるかに小さいものです。

個人的には、適切に設計されたコメット サーバーが、多数の更新やサーバー プッシュに最適なソリューションであることがわかりました。

Answer 3

StreamHub GWTコメットアダプターは、株価をストリーミングするこのシナリオのために正確に設計されました。ここでの例：GWT StreamingStockQuotes。複数の株の株価を同時に更新します。その下の実装は、本質的にHTTPを介してストリーミングしているCometだと思います。

編集：ブラウザごとに異なる手法を使用します。ウェブサイトを引用するには：

Cometの実装に使用される基本的な手法には、Hidden iFrame、XMLHttpRequest / Script Long Polling、Flashなどの組み込みプラグインなどがあります。将来のブラウザにHTML5WebSocketが導入されると、HTTPストリーミングの代替メカニズムが提供されます。StreamHubは、各ブラウザーで最もパフォーマンスが高く信頼性の高い手法を利用した「最適な」アプローチを使用します。

Answer 4

ライブ株価の場合、私は絶対に接続を開いたままにし、切断時にユーザーのアラート/再接続を確実にします.

Answer 5

データは一方向にのみネットワークを通過するため、ストリーミングは高速になります。ポーリングを使用すると、レイテンシは少なくとも 2 倍になります。

ポーリングは、開いたままの接続に依存しないため、ネットワークの停止に対してより回復力があります。

堅牢性のためだけにポーリングに行きます。