クライアント通知。AJAX プッシュまたはポーリングを使用する必要がありますか?
-
03-07-2019 - |
質問
私は、Web サイトを閲覧しているユーザーにメッセージを配信するために使用される単純な通知サービスに取り組んでいます。通知はリアルタイムで送信する必要はありませんが、5 分ごとよりも頻繁に通知が送信されると、ユーザー エクスペリエンスが向上する可能性があります。クライアントとの間で送受信されるデータはそれほど大きくないため、データを取得するのは単純なデータベース クエリです。
このトピックに関する他の会話を読むと、AJAX プッシュによりサーバーの負荷が高くなる可能性があることがわかります。サーバーの遅延が長くても許容できるので、サーバーにプッシュ通知を送信するか、単にポーリングするだけの価値がありますか。
プッシュ シナリオの実装はそれほど難しくないので、ここでどのような意見があるかを確認してみようと思いました。
ご協力いただきありがとうございます。
編集:私は単純な AJAX Push を検討し、これに基づいて簡単なデモを実装しました。 記事 マイク・パーヴィス著。クライアントの負荷は初期バージョンでは約 5,000 とかなり低く、かなり長い間その状態が続くことが予想されます。
皆様、ご回答ありがとうございました。私はポーリング ソリューションを使用することにしましたが、後で変更したくなった場合に簡単に変更できるように、すべてをユーティリティ ライブラリ内にラップすることにしました。
解決
プッシュを使用するには、サーバーと各クライアント間で開かれたHTTP接続を維持する必要があるため、ポーリングも行います-サーバーリソースを大量に消費するだけでなく、前述のmatt bのように実装するのはさらに難しい。
ポーリングに関する私の経験では、忙しいサイトで頻繁に十分なポーリング間隔がある場合、Webサーバーのログはすぐにポーリングリクエストであふれることがあります。
編集(2017):あなたの選択は、websocketsとlong polling(別の回答で述べられている)の間にあると思います。質問は、通知をリアルタイムで受信する必要がないと述べている方法に基づいて、長いポーリングが正しい選択であるように思えます。頻繁に行われないポーリング期間は実装が非常に簡単で、サーバーにあまり負担をかけるべきではありません。 Websocketはクールで、最近の多くのアプリケーションに最適な選択肢ですが、この場合はやり過ぎかもしれません。
他のヒント
ここでは誰もロングポーリングについて言及していないことに驚いています。長いポーリングとは、開いた接続をより長い期間(30〜60秒など)維持し、いったん閉じてから再度開き、ソケット/接続が応答をリッスンするようにすることです。これにより、接続は少なくなります(ただし、接続は長くなります)。つまり、応答はほとんど即時に行われます(新しいポーリング接続を待たなければならない場合があります)。これをNodeJSなどのテクノロジーと組み合わせて追加したいと思います。これにより、すべての主要なブラウザーとバージョンで100%のブラウザー互換性があり、Cometやフラッシュ。
これは古い質問であることがわかりましたが、この情報を提供することはまだ有用だと思いました:)
pushを使用すると、pushのずっとクールなものになります。単純な通知だけが必要な場合は、 StreamHub Push Server のようなものを使用して、面倒な作業を行います。独自のAjaxプッシュ機能を開発することは非常に困難で困難な道です。すべてのブラウザーで機能させ、キープアライブ接続を殺すファイアウォールやプロキシを処理する必要があります...車輪を再発明する理由。また、10K未満の同様に低いフットプリントを持っているので、それがあなたにとって優先事項であるならばそれは合うはずです。
両方に異なる要件があり、異なるシナリオに対処します。
オンラインチャットのように、リアルタイム更新が必要な場合は、プッシュが必須です。
しかし、更新期間が長い場合、あなたの場合のように(5分)、プールが適切なソリューションです。この場合、プッシュはクライアントとサーバーの両方から大量のリソースを必要とします。
ヒント!プールを高速かつクリーンにチェックするページを作成して、各リクエストでサーバーのリソースを大量に消費しないようにします。私が通常行うことは、プールが空であるかどうかを示すフラグをメモリに保持することです(セッション変数など)。したがって、プールが空でない場合にのみ、プール内のヘイビールックを行います。プールが空の場合(ほとんどの場合)、ページリクエストは非常に高速に実行されます。
私がアンケートを実装するのは、その方が簡単に書けるように思えるからであり、シンプルに保つことは非常に価値があるからです。
いくつかのCOMET実装をご覧になっているかどうかはわかりません(AJAXプッシュという意味です)。
ユーザーがサイトを閲覧している場合、実際にはサーバーからこの通知が便乗できる情報を要求しているのではないでしょうか
クライアントの数を知らずにプッシュするよりもポーリングの方が高いかどうかを判断することは不可能です。ポーリングをお勧めします:
- 1分に1回程度データを更新したいようです。通知がそれよりもはるかに速い速度で届かない場合を除き、プッシュすると、HTTP接続は開いたままですが、アクティビティがほとんど表示されなくなります。
- ポーリングは既存のHTTP規則に基づいて構築されているため、Webブラウザーと通信するサーバーは通常のAjaxリクエストに応答する準備がすでに整っています。彗星–または、フラッシュソケット–ベースのソリューションには異なる要件があります。サーバー側の
cometd
のようなものと、サーバー側のプッシュを吸収するクライアント側のライブラリが必要になります。
したがって、データの急流とクライアントの膨大な量を管理するために強力な何かが必要な場合は、Cometをお勧めします。しかし、そうではないようです。
http://pusherapp.com というサービスがあり、この問題を一度だけ解決しようとしています。点滅。チェックアウトする価値があるかもしれません。 (免責事項:私は彼らとは一切関係ありません)。
自分で試したことはありませんが、 COMETが機能し、思っているより簡単です。 Juggernaut というRuby on Railsプラグインもあります。繰り返しになりますが、YMMVは使用していませんが、ポーリングに比べてはるかに少ないリソースで済むことを理解しています。 COMETは MacRumorsLive.com がWWDC Stevenotesのライブブログを配信する方法だと信じています(誰か確認できますか?)。 / p>