83

私はリアルタイムのWebアプリケーションを構築しています。私が知る限り、最も人気のある選択肢は、短いポーリングと長いポーリングです。どちらか一方を測定することには、どのような長所と短所がありますか？

4

3 に答える 3

102

議論のために。

どちらも 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-> Yes. 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-> Yes.Have 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 を使用すると仮定します。これは、40 の長いポーリング接続スクリプトしか取得できないことを意味します。

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

ウェブソケット

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

socket.io などの一部のライブラリには独自の階層があるため、websocket が失敗すると、ロングまたはショート ポーリングに戻ります。

いつ使用するか。

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

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

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

于 2015-01-28T16:54:01.097 に答える
75

  • 短いポーリング (別名 AJAX ベースのタイマー):

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

  • ロングポーリング (別名 XHR ベースのコメット)

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

于 2011-01-17T14:11:51.577 に答える
1

データベースに基づいてリアルタイムのアプリケーションを取得したい場合は、ajax long poll と comet の組み合わせを使用できます。 長いポーリングは帯域幅に非常に適しているだけでなく、ユーザー MB にとっても非常に便利です。ユーザーが要求を送信するときに、ユーザーは MB やある種のインターネット接続などの料金を支払うためです。たとえば、要求ごとに送信するような何かを行うときの短いポーリング2 番目のユーザーのインターネット使用量は、各接続ユーザーが料金を支払うため (ユーザーが Mb を失うことを意味します)、より多くなりますが、長いポーリングでは、ユーザーのみが新しいメッセージに対してのみ料金を支払います。

Websocketは非常に優れた機能ですが、Websocket は単に新しいバージョンのブラウザー用であるため、多くの人がチャット システムを使用できないという大きな問題を考慮する必要があります。

于 2016-04-29T06:10:34.850 に答える