1

多くのメディア エンコーディングを行う Rails アプリケーションがあります。バックグラウンド プロセスを介して処理していますが、CPU が過負荷になり、フロント エンドの読み込み時間が本来よりも明らかに遅いことがわかります (または、バック エンド部分が大きくなる前でした)。

問題: メディア エンコーディング機能を備えた Rails アプリでは、CPU 負荷が発生し、フロントエンドが遅くなります。目標 - フロントエンドとバックエンド (メディア エンコーディング) 部分を分離します。

質問 - 既存のアプリケーションを 2 つの部分 (フロントエンド部分とバックエンド部分) に分割する最善の方法は何ですか?

1) 2 つのサーバーでアプリの 2 つのコピーを実行し、HTTP 経由で情報を POST/PUT する (またはリモート データベースに接続する) 間に呼び出しを行うことをお勧めしますか?

2) CPU を集中的に使用する部分を Rails コードにまとめておくのは良い考えですか、それとも Rails の機能から取り除くことを目指すべきですか?

誰かがマルチサーバー Rails アプリケーションの実行に関する優れたガイドを指摘できれば、それは素晴らしいことです (検索するとマルチサーバー Capistrano の展開に関する質問が返されますが、あまり具体的でないレシピが必要です)。

4

1 に答える 1

0

うまく機能する一般的なアプローチは、Resqueのようなワーク キューを使用することです。

コード
の管理 管理を容易にするために、処理コードとアプリを「アプリ内」に保持します。2 つのアプリ サーバーをデプロイしますが、処理サーバーで resque ワーカーを実行します。

状態の変化
処理ジョブが ActiveRecord の永続オブジェクトに関連する場合、フロントエンドから状態をポーリングし、エンコーディング プロセス中にバックエンドから定期的に更新することができます。

ステート マシンを使用すると便利な場合があります。

問題は解決しました
。これでクラウド スケール™ です:D キューが長くなりすぎた場合は、ワーカーを実行する処理ホストをさらに追加できます。フロントエンドが Web アクセス可能な唯一のホストである場合は、ラック ミドルウェアをセットアップするか、レインボーを実行して、フロントエンドを介して処理された結果をクライアントにプロキシすることができます。

興味深いプロジェクトのようですね。幸運を!

于 2012-08-16T00:50:04.297 に答える