web-dev-qa-db-ja.com

リアルタイムWebアプリケーションのショートポーリングとロングポーリング

私はリアルタイムWebアプリケーションを構築しています。私の知る限り、最も一般的な選択肢は、ショートポーリングとロングポーリングです。一方を他方に対して測定する場合の利点と欠点は何ですか？

javascripthttpcometreal-timelong-polling
57
Jeff

  • 短いポーリング（別名AJAXベースのタイマー）：

    長所：サーバーの消費ではなく、シンプルです（リクエスト間の時間が長い場合）。
    短所：サーバーイベントが遅滞なく発生したときに通知を受ける必要がある場合は悪いです。 例 （ ItsNat ベース）

  • ロングポーリング（別名XHRに基づく彗星）

    長所：サーバーイベントが遅延なく発生すると通知されます。短所：より複雑でより多くのサーバーリソースが使用されます。 例 （ItsNatベース）

54
jmarranz

議論のためだけに。

両方ともhttpリクエスト（xhr）であり、少なくとも部分的には正しくありません（より多くのサーバーリソースを使用します（技術に完全に依存します。後で説明します））。

短いポーリング。

サーバーに到着したときに処理される多くのリクエスト。多くのトラフィックを作成します（リソースを使用しますが、応答が返されるとすぐにそれらを解放します）。

00:00:00 C-> Is the cake ready? 
00:00:01 S-> No, wait.
00:00:01 C-> Is the cake ready?
00:00:02 S-> No, wait.
00:00:02 C-> Is the cake ready? 
00:00:03 S-> Yeah. Have some lad.
00:00:03 C-> Is the other cake ready? ..

長いポーリング

1つの要求がサーバーに送られ、クライアントは応答が来るのを待っています（未解決）。 php/Apacheを備えたサーバーの場合、処理するスレッドが生成され、リソースが予約されるまでリソースを予約します。そのため、トラフィックは小さくなりますが、リソースをすぐに使い果たします（または、リソースをブロックします）。ただし、たとえばNode（または他の非同期アプローチ-たとえばc ++ qt））を使用すると、リソース使用量を大幅に最小化できます（http要求の応答オブジェクトを保存し、仕事の準備ができました）

12:00 00:00:00 C-> Is the cake ready? 
12:00 00:00:03 S-> Yeah.Hame some lad.
12:00 00:00:03 C-> Is the cake ready?

これをショートポーリングと比較すると、ショートポーリングではより多くの転送を使用した可能性がありますが、3秒間は実際に1,5秒間の処理時間がかかります（呼び出しの間に何かが実行される可能性があることを意味します）。長いポーリングの場合、同じリソースが常に使用されました。現在、通常、すべてのライブラリを含むphpは4MBのメモリで始まります-4〜20MBのフレームワークがあります。 1024MB RAMが利用可能（無料）であると仮定します。悲観的に考えて、1つのphpインスタンスごとに25 MBを使用すると仮定します。 。

Nodeがインスタンスを生成しないので（Nodeがワーカーなどを使用しない限り）、Nodeでより多くのサービスを提供できる理由はまさにそのため、同じメモリを使用すると、おそらく10kの接続がハングする可能性があります。来るとCPUが急上昇する可能性があり、解放される可能性がありますが、アイドル状態のときは存在しないようです（node/c ++に保持するメモリ構造に対してのみ支払います）。

Websocket

クライアントに出入りするときはいつでも、いくつかのものを送信する場合は、websockets（wsプロトコル）を使用します。最初の呼び出しはHTTPリクエストのサイズですが、後でメッセージを送信するのは、クライアントからサーバー（新しい質問）、サーバーからクライアント（応答またはプッシュ-接続されているすべてのクライアントに対してブロードキャストを行うこともできます）です。 php websocekts libsがありますが、ここでもいくつかの異なるテクノロジーを使用してください-nodeまたはc ++が望ましいです。

Socket.ioのような一部のライブラリには独自の階層があるため、websocketが失敗すると、長いポーリングまたは短いポーリングに戻ります。

いつ使用するか。

短いポーリング-まあ、決して^^。

ロングポーリング-サーバーとの単一の通話を交換していて、サーバーがバックグラウンドで何らかの作業を行っている可能性があります。また、同じページのサーバーにクエリを実行しなくなった場合。また、長いポーリングされた接続を処理するレイヤーとしてphpを使用していない場合（node/c ++は単純な中間レイヤーでもかまいません）。長いポーリングは本当に有益ですが、そうする場合にのみ注意してください。

Websocket-1つまたは2つ以上の呼び出しをサーバーと交換する可能性があります。または、メールや何かの通知など、予期しない/要求していないサーバーから何かが来る可能性があります。機能に応じて、さまざまな「部屋」を計画する必要があります。 javascriptのイベントベースの性質を受け入れます;]

51
sp3c1

データベースに基づいてリアルタイムのアプリケーションを取得したい場合は、ajaxの長いポーリングと彗星の組み合わせを使用できます。 Long pollは帯域幅に非常に有効であり、ユーザーMBにも非常に便利です。たとえば、Short pollの場合、ユーザーごとにリクエストを送信するなどの操作を行うと、各接続ユーザーが料金を支払うため、インターネットの使用量が多くなりますit（ユーザーがMbを失うことを意味します）が、長いポーリングユーザーでは新しいメッセージに対してのみ支払います。

Websocketは本当に良いことですが、それを使用するときは、Websocketが新しいために多くの人がチャットシステムを使用できないという1つの大きな問題について考える必要がありますブラウザのバージョン

0
Ibrahim Hasanov