問題タブ [eventmachine]

URL への同期要求を行うことができる Ruby で記述された Http クライアントがあります。しかし、複数のリクエストをすばやく実行するために、Eventmachine を使用することにしました。アイデアは、すべてのリクエストをキューに入れ、eventmachine を使用してそれらを実行することです。

グローバル キュー変数の使用を許してください。後でリファクタリングします。EventMachineBackend#executeEventmachine キューを使用する正しい方法で行っていることはありますか?

私の実装で見られる 1 つの問題は、それが本質的に同期的であることです。リクエストをプッシュし、ポップしてリクエストを実行し、完了するのを待ちます。

誰でもより良い実装を提案できますか。

Rails で EventMachine を使用したいと考えており、入手できる EventMachine 関連の記事を読んでいます。それらのほとんどは EM の単純なスタンドアロンの例を備えているため、分解するために EM を備えた完全なオープン ソース アプリを探しています。助けてください？

私は現在、ユーザーがアップロードしたビデオを linode サーバーにトランスコードし、s3 を使用してそれらを保存していますが、私は楽観主義者なので、トランスコーディングを Amazon EC2 に移動して、必要に応じてスケールアップし、それを使用して経験を積みたいと考えています。これまでの私のワークフローは次のとおりです。

1. nginx/Rails スタックをバイパスして、動画を s3 に直接アップロードする
2. ビデオ URL を使用して Amazon シンプル キュー サービスにエントリを作成する
3. EC2 のインスタンスが実行されているかどうかを確認します。そうでない場合は、起動スクリプトとして単純な ruby​​ スクリプトを使用して起動します (Amazon は 6kb 未満の起動スクリプトを許可していると思います)。
4. Ruby スクリプトは単純なキューに接続し、ffmpeg コマンドを実行してビデオをトランスコードします
5. スクリプトは、追加のキューがあるかどうかを確認して実行します
6. キューがなくなったらインスタンスをシャットダウンします (EC インスタンスが実行されている時間の任意の部分に対して Amazon が 1 時間分の料金を請求するため、1 時間実行する可能性があります)。

明らかに、上記は基本的なものであり、EC2 を完全には使用していません。スレッドを使用してキューに接続し、同じ EC2 インスタンスで新しいジョブを実行するか、起動スクリプトが ruby​​ スクリプトを実行する追加の EC2 インスタンスを作成することを考えました。前者では、CPU 使用率に基づいて同じ EC2 内のジョブ数を制限する必要があります。

後者は無駄に思えますが、ビデオ トランスコーディングは CPU を集中的に使用するため、2 つの ffmpeg を同時に実行するのは現実的ではありません。新しいインスタンスを作成するために Amazon の自動スケーリングについても考えましたが、Ruby を使用する方が簡単で簡単に思えます。

1. 私の質問は、これを効率的に行うための最良の方法は何ですか?
2. 2 つの ffmpeg を実行することは悪い習慣と見なされますか? (ビデオ サイズが平均約 200 mbs になると仮定しましょう。)
3. Rubyスレッドの使用は、名前が悪いように見えるため、最適ですか?
4. スレッドの代わりに EventMachine を調べる必要がありますか?

必要な場合を除き、EC2 インスタンスを実行したくありません。インスタンスを最大限に活用しますが、動画がトランスコードされるまでユーザーを長時間待たせたくありません。

この記事に基づくhttp://stream0.org/2009/10/h264-video-encoding-on-amazons.htmlhttp://stream0.org/2009/10/h264-video-encoding-on-amazons.html 高-CPU、エクストラ ラージ インスタンスが最適なオプションのようです。もちろん、私自身のテストをいくつか行う予定ですが、飛び込む前に専門家の意見を聞きたかったのです。ありがとう!

エッセイになってしまいました、長文失礼しました。

EventMachine でいくつかのジョブをバックグラウンド化する可能性を検討しています。Sinatra ではこれはうまく機能しているように見えますが、Rails 3 はビューをレンダリングする前にすべてのティックを実行しているようです。

シン Web サーバーで次のコードを実行すると、期待どおりに動作します。最初のリクエストはすぐに返され、2 番目のリクエストは 3 秒間のスリープ コールが終了するのを待っています。これは予期される動作です。

一方、Rails 3の実行中は同じことをしようとしています:(シンの下で実行)

Rails では、ブラウザにビューをレンダリングする前に sleep 呼び出しが発生します。その結果、最初のページがレンダリングされるまで 3 秒間待機しています。

なぜこれが起こっているのか誰にも分かりますか？これが良い習慣であるかどうかについてのコメントは求めていません。私は単に実験しています。小さなタスクをリアクター ループに投入することは、興味深い調査のように思えます。ノンブロッキングの http リクエストを行う場合、なぜクライアントを待たなければならないのでしょうか?

同期が必要で、選択肢が多すぎます。利用可能なオプションには、Faye、Juggernaut、Cool.io、昔ながらの eventmachine などがあります。

助言がありますか？特に RoR コミュニティで最も人気のあるものは何ですか?

あなたの提案についての説明をありがとう。

1 つのスクリプトがファイルから読み取り、別のスクリプトに 1 行ずつデータを送信し、「サーバー」スクリプトがそのデータに基づいて動作する eventmachine アプリがあります。残念ながら、「サーバー」スクリプトは正常に実行receive_dataされません。接続が行われていることは eecutespost_initであることを知っており、sender スクリプトがデータを送信していることも知っています。これは、サーバーの起動方法と一緒に私のコードの一部です。

注: モジュールの定義は、サーバー スクリプトに必要なクラスと一緒に、別のファイルに格納しています。

私はsnedメールシステムを持っています.私はメールを送信するためにEventMachineを使用しています.しかし、私が送信したメールを受信したとき、私はhtmlコードを取得しましたが、htmlビュー.

EventMachine で conent_type = 'text/html' を設定するには?

THX

ネットワーク クライアントのセットからデータを受け取り、それをデータベースに記録し、同時に別のクライアント セットに送信する単純な EventMachine プロジェクトの作業を開始しました。A クライアント => B クライアントの部分は、reactor が非常に簡単にするようなものですが、データベースへのアクセスはそれほど多くはありません。私が知っていて大好きなすべての ORM 抽象化を提供しながら、EventMachine でうまく機能する方法で非同期アクセスをサポートする適切な ORM を見つけようとしています - たくさんのソケットを開いて SQL について話し合うことを避けたいと思っています。彼ら！また、DB サポートの合理的な広がりを維持することが望ましいです (たとえば、非同期 ActiveRecord を mysql のみで動作させる方法を説明する記事をいくつか見ました)。

これまでのところ、私が見つけたのはswiftだけです。これはうまくいくように見えますが、ActiveRecord や DataMappers と比較すると非常に少ないようです。

ここで追求する価値のある他の道はありますか? おそらく、主要な ORM パワーハウスの 1 つに、あまり知られていない非同期ブランチがあるのでしょうか? :P

私は分散 Web クローラーを構築しており、各マシンのリソースを最大限に活用しようとしています。EventMachine で Iterator を介して解析関数を実行し、em-http-request を使用して非同期 HTTP 要求を作成します。今のところ、同時に実行する反復が 100 ありますが、このレベルを超えることはできないようです。反復回数を増やしても、クロールの速度には影響しません。ただし、CPU 負荷は 10 ～ 15%、ネットワーク負荷は 20 ～ 30% しかないため、クロールを高速化する余地は十分にあります。

Ruby 1.9.2 を使用しています。リソースを効果的に使用するためにコードを改善する方法はありますか、それとも間違っているのでしょうか?

私は自分のイベントマシンベースのアプリケーションをruby-profでプロファイリングし、次のことを興味深いと感じました。

ruby-profはCPUティックのみをカウントするため、ミューテックススリープにCPU時間がかかる理由を理解できません。ファイバー時間にはカウントされず、カーネルレベルでスリープすると思います。何か案は？さらに良いことに、Mutex＃sleepがイベントマシンに制御を解放して、他のことを実行できるようにしたいと思います。