4

Rails アプリ (Phusion パッセンジャー サーバー) でユーザーにリアルタイム フィードを実装する良い方法を探しています。各フィードはユーザーによって異なる可能性があり、20 ~ 60 秒ごとに 1 つの新しいアイテムがあると予想しています。定期的な ajax リクエストは、私にとって最善の方法とは思えません。

Comet について聞いたので、次のようなことを考えました: - XMLHttpRequest ロング ポーリングを使用して、サーバーからの ping を待機する - サーバーが ping リクエストを送信したら、最新のアイテムを ajax で送信する - 別の XMLHttpRequest を開始する

これに何か問題がありますか?それを行うためのより簡単でより良い方法はありますか?

ありがとう、S.

4

2 に答える 2

4

Webアプリケーション(および拡張機能としてRailsアプリケーション)に関しては、リアルタイムは単なる幻想です。長いポーリングは非常に近い近似値です。残念ながら、Railsにはあまり適していません。乗客についてはさらに少ない。

長いポーリングでは、ユーザーごとに永続的なオープン接続が必要です。これは、それを処理するように設計されていないサーバー(Apacheなど)ではあまり拡張できません。残念ながら、Railsでうまく機能する長いポーリングスケーラビリティ用に設計されたサーバーは本当にたくさんあります。Shooting-Starサーバーを試すこともできますが、標準的なリクエストでは、そのパフォーマンスがPassengerとどのように比較されるかはわかりません。

長いポーリングについての私の個人的な意見は、それは問題を必要としている解決策だということです。

本当にあなたは自分自身に次の質問をするべきです:

  • これらの更新は、40秒待つことができないほど高い優先度ですか?
  • 更新がすぐに受信されない場合はどうなりますか?
  • 私のユーザーは私のアプリケーションに集中しすぎて、15秒待つとエクスペリエンスに悪影響を及ぼしますか?
  • 私のアプリケーションは、通常の使用でユーザーの注意を何パーセント引き付けますか?
  • 更新に応答するのにどのくらい時間がかかりますか?
  • 本当にリアルタイムである必要がありますか?

それらの質問のいくつかは別の方法で他の質問をしているが、それはそのような主観的な質問ではある種必要である。

私が得ているものがわかると思います。リアルタイムの更新は非常に便利ですが、実際には必要ありません。リアルタイムの更新に反応しなかった結果が世界の終わりである何かに取り組んでいる場合。あなたは本当にそれをウェブアプリケーションとして開発するべきではありません。

リアルタイムの更新についてまだ気になっている場合は、Juggernautを調べることができます。しかし、それはFlashベースのソリューションです。

于 2009-11-05T18:37:15.933 に答える
4

Friendfeedは Python でTornado サーバーを構築し、オープン ソース化しました。

nginx_http_push_moduleを使用する前に、セットアップが非常に複雑な多くの XMPP オプションを調べました。有効期間の長い HTTP GET リクエストはこれに接続し、Rails アプリはリクエストを nginx にプッシュします。Nginx はまた、動的リクエストを雑種のクラスターにプロキシします。接続を開き、メッセージを受信したとき、またはエラーが発生したときにサーバーに対して再度開く jQuery を実行しています。このようにして、Comet スタイルでほぼリアルタイムの更新を実現できます。

Ruby の例を含む nginx モジュールに関するこのブログ投稿は、開始するのに役立ちます (nginx をコンパイルする必要があります)。これは現在開発段階で実行されており、信頼性が低いことが証明されない限り、本番環境で使用する予定です。

于 2009-11-06T06:10:01.423 に答える