AJAX を使用してレールにスケーラブルなチャットルームを実装したいと考えています。調査によると、スケーラビリティはサーバー側のプッシュでのみ発生することがわかっています。
私の2つの質問は次のとおりです。
1) 合理的に効率的なチャット サーバーでは、どの時点でポーリングが禁止されますか? 2) 本当にジャガーノートは使いたくない。彗星の仕組みはよくわかりません。Javascript (クライアント側のサーバー/ポーラーを作成するため) と別の言語 (ファイアウォールの背後にあるクライアントに効率的なポーリングと CGI への統合を提供するため) を使用して構築するのは、私にとって非常に難しいのではないかと思います。そして 3) (はい、2 つのうち)、私はそれを正しい方法で行っているかどうか?
私が期待できる最も簡単な答えは、定量化された「はい、5行のJavascriptをクライアントに入れ、20行のRubyをCGIスクリプトに入れ、それを1日と呼びます」です。
私は今同じことをしようとしています。Juggernautはうまく機能しますが、Rails 3では機能しません。それが必須でない場合は、チャットを行うのが非常に簡単なので、Juggernautを使用することをお勧めします。私のプロジェクトはRails3を使用し、3秒ごとにサーバーをポーリングします（Campfireも3を実行します）。Rails Metalを使用して、ポーリングを超高速にします。Juggernautを使用する場合は、クライアント側のjsを2行、サーバー側を1行または2行使用します。それ以外の場合は、仕事に取り掛かります！
はい、5行のJavascriptをクライアントに入れ、20行のrubyをCGIスクリプトに入れて、それを1日と呼びます
キャンプファイヤーはどうですか？5 秒ごとにサーバーをポーリングします。夢のように機能します。
COMET は、サーバーへの接続を Javascript で開いたままにすることで機能します (COMET の Web サイトには、この非同期データを取得する方法の例がたくさんあります)。サーバーは基本的にデータを書き出してフラッシュします。これは、密なループで Mutex を使用して行うことができます。また、ある種のメッセージ キューも必要になるでしょう。
長期的にはBOSHについて学んでおいたほうがいいかもしれません。COMETからの自然な流れです。
Juggernaut には学習曲線がありますが (実際にはそうではないかもしれません)、COMET の方法を学習するのはより急勾配です。非同期プッシュだけでも難しいです。それだけでなく、適切にスケーリングする方法を検討する必要があります。私は Juggernaut を使ったことはありませんが、ROR プラグインに関する限り、些細なことだと思います。また、スケーリングを改善する方法を見つければ、無料でより高速なパフォーマンスを得ることができます。
ポーリングは、技術的にはより簡単に機能する別のオプションですが、サーバーを停止させる可能性があるため、ポーリングを使用しないことに情熱を注いでいます。ポーリングは怠惰な方法だと思うので、ここでは詳しく説明しません。