33

私は、ウェブサイトを閲覧しているユーザーにメッセージを配信するために使用される単純な通知サービスに取り組んでいます。通知はリアルタイムで送信する必要はありませんが、たとえば 5 分ごとよりも頻繁に送信した方が、ユーザー エクスペリエンスが向上する可能性があります。クライアントとの間で送受信されるデータはそれほど大きくなく、データを取得するための単純なデータベース クエリです。

このトピックに関する他の会話を読むと、AJAX プッシュによってサーバーの負荷が高くなる可能性があるようです。サーバーの遅延が長くなっても許容できるので、サーバーにプッシュ通知を送信するか、単にポーリングするだけの価値があります。

プッシュシナリオを実装するのはそれほど難しくないので、ここで意見が何であるかを見てみたいと思いました.

ご協力いただきありがとうございます。

編集:私は単純な AJAX プッシュを調べ、Mike Purvis によるこの記事に基づいて単純なデモを実装しました。初期バージョンのクライアント負荷は約 5k とかなり低く、かなりの期間その状態が続くと予想されます。

皆様、ご回答ありがとうございます。私はポーリング ソリューションを使用することにしましたが、後で変更したい場合に簡単にできるように、すべてをユーティリティ ライブラリ内にラップすることにしました。

4

9 に答える 9

13

ここで誰もロングポーリングについて言及していないことに驚いています。長いポーリングとは、接続を長期間（たとえば、30〜60秒）開いたままにし、閉じたら再度開いて、ソケット/接続に応答をリッスンさせることを意味します。これにより、接続が少なくなり（ただし、接続が長くなります）、応答がほぼ即時に行われることを意味します（新しいポーリング接続を待たなければならない場合もあります）。これをNodeJSのようなテクノロジーと組み合わせて追加したいのですが、これにより、非常に効率的でリソースの少ないソリューションが実現します。これは、すべての主要なブラウザーとバージョンで100％ブラウザー互換であり、CometやCometなどの追加のテクノロジーを必要としません。閃光。

これは古い質問だと思いますが、この情報を提供することはまだ役立つかもしれないと思いました:)

于 2013-01-03T05:25:15.093 に答える
10

間違いなく、はるかにクールなプッシュを使用してください。簡単な通知だけが必要な場合は、StreamHub Push Serverのようなものを使用して面倒な作業を行います。独自の Ajax Push 機能を開発することは、非常にトリッキーで困難な道のりです。すべてのブラウザーで動作するようにし、その後、キープアライブ接続を強制終了するファイアウォールやプロキシを処理する必要があります。車輪を再発明する必要はありません。また、フットプリントが 10K 未満と同様に小さいため、それが優先事項である場合に適しています。

于 2009-07-31T00:52:47.637 に答える
7

どちらも要件が異なり、対応するシナリオも異なります。

オンライン チャットのようにリアルタイムの更新が必要な場合は、プッシュが必須です。

ただし、あなたの場合のように更新期間が長い場合 (5 分)、プールが適切なソリューションです。この場合、プッシュはクライアントとサーバーの両方から多くのリソースを必要とします。

ヒント！プールをチェックするページを高速かつクリーンに作成して、各リクエストでサーバーのリソースを大量に消費しないようにしてください。私が通常行うことは、プールが空かどうかを示すフラグを (セッション変数のように) メモリに保持することです...そのため、プールが空でない場合にのみプールを調べます。ほとんどの場合、プールが空の場合、ページ要求は非常に高速に実行されます。

于 2008-10-21T02:07:38.487 に答える
5

プッシュを使用するには、サーバーと各クライアントの間でオープンな HTTP 接続を維持する必要があるため、ポーリングも使用します。これは多くのサーバー リソースを消費するだけでなく、非常にトリッキーになります。マットbが述べたように実装します。

ポーリングに関する私の経験では、十分に忙しいサイトで十分な間隔でポーリングを行うと、Web サーバーのログがポーリング要求ですぐにあふれてしまう可能性があります。

編集（2017）：あなたの選択は、Webソケットとロングポーリングの間であると思います（別の回答で言及されています）。質問が通知をリアルタイムで受信する必要がないことを述べている方法に基づいて、長いポーリングが正しい選択である可能性があるように思えます。まれなポーリング期間は実装が非常に簡単で、サーバーに大きな負担をかけるべきではありません. Websocket はクールで、最近の多くのアプリケーションにとって最適な選択肢ですが、この場合はやり過ぎかもしれません。

于 2008-10-20T21:00:08.607 に答える
3

書くのが簡単に聞こえるという理由だけでポーリングを実装し、シンプルに保つことは非常に価値があります。

于 2008-10-20T20:53:24.953 に答える
1

クライアントの数がわからなければ、ポーリングがプッシュよりもコストがかかるかどうかを判断することは不可能です。次の理由から、ポーリングをお勧めします。

  • 1分に1回程度データを更新したいようです。通知がそれよりもはるかに速い速度で到着できない場合を除き、プッシュは、HTTP 接続を開いたままにしておくことを意味しますが、その上でほとんどアクティビティが見られません。
  • ポーリングは既存の HTTP 規約の上に構築されているため、Web ブラウザーと対話するサーバーは、通常の Ajax 要求に応答する準備が整っています。コメットまたはフラッシュ ソケット ベースのソリューションには、さまざまな要件があります。サーバー側のようなものcometdと、サーバー側のプッシュを処理するクライアント側のライブラリが必要になります。

したがって、データの急流と大量のクライアントを管理するために重いものが必要な場合は、Comet をお勧めします。しかし、そうではないようです。

于 2008-10-20T21:45:13.680 に答える
1

現在、この問題を一気に解決しようとするサービスhttp://pusherapp.comがあります。チェックアウトする価値があるかもしれません。（免責事項：私は決して彼らとは関係ありません）。

于 2011-08-04T20:52:14.270 に答える
1

いくつかの COMET 実装を調べたかどうかはわかりません (それが AJAX プッシュの意味です)。

ユーザーがサイトをサーフィンしている場合、それは事実上、この通知がピギーバックできるサーバーからの情報を要求しているのではないでしょうか?

于 2008-10-20T20:57:21.747 に答える
1

私は自分で試したことはありませんが、COMET が機能し、思ったより簡単だと言う人もいます。Juggernautと呼ばれる Ruby on Rails プラグインもあり、非常に話題になっていると聞いています。繰り返しますが、私はそれを使用していないので YMMV ですが、私の理解では、ポーリングに比べてはるかに少ないリソースで済みます。COMET は、MacRumorsLive.com が WWDC のStevennotesのライブ ブログを提供する方法だと私は信じています (誰か確認できますか?) 。

于 2008-10-20T21:14:21.883 に答える