1

メールやユーザー通知の遅延など、さまざまなデータベース タスクを実行するカスタム デーモンを作成しようとしています (各通知は通知テーブルの個別の行です)。script/runnerこれらのタスクを使用したり実行したりしたくありませんrake。タスクによっては、1 つまたは 2 つのデータベース行または数千行の作成しか必要としないタスクもあるからです。Ruby プロセスを起動したり、操作ごとに Rails フレームワーク全体をロードしたりするオーバーヘッドは必要ありません。このデーモンを常にメモリに保持する予定です。

このデーモンを作成するには、Ruby on Rails アプリケーションのモデルを使用したいと考えています。モデルをどこで使用する場合にロードする必要があるかなど、多くの Rails プラグインacts_as_treeがあります。AASMロードする必要があるプラグインのいくつかは、私が作成した ActiveRecord::Base のカスタム ハックです。(レールの他の部分からのコンポーネントが必要な場合は、プラグインの一部の削除または再コーディングを喜んで受け入れます。)

私の質問は

  • これは良い考えですか？
  • そして - モデルとプラグインに各ファイルを手動で含める必要がない方法でこれを行うことは可能ですか?

良い考えでなければ

  • 良い代替手段は何ですか？

(私は自分で SQL クエリを書くのは好きではありませんが、愚かな事故を防ぐために、データベースの制約とデーモン用の別のユーザーを追加する必要があります。データベースの構成に慣れていないので、アクティブ レコードを使用したいと思います。松葉杖として。）

4

2 に答える 2

0

あなたの懸念は、タスクを実行する必要があるたびに Rails スタックをスピンアップするために時間やメモリのコストを払いたくないということのように思えますか? あなたが言うように、デーモンをフルタイムで実行し続けることを計画している場合は、Rails スタックをロードしたプロセスをデーモン化するだけでよく、スタックを 1 回ロードするためのメモリまたは時間関連のペナルティを支払うだけで済みます。デーモンが起動します。

Async_workerは、この種のパターンの良い例です。Beanstalk を使用して、完全な Rails スタックをロードした単なるデーモンである 1 つ以上のワーカー プロセスにメッセージを渡します。

これを行う際に注意しなければならないことの 1 つは、デプロイ時にデーモン化されたプロセスを再起動して、更新された Rails スタックをリロードできるようにする必要があることです。私はこれをURL短縮アプリに使用しています（私が実行している単一の非同期ワーカープロセスは、訪問者がリダイレクトされた後に参照データを保存するために待機しています）、うまく機能しafter:deployます.非同期ワーカーを再起動するカピストラーノタスクがあります（秒）。

于 2009-11-18T20:49:43.757 に答える
0

ActiveRecord などの Rails の 1 つの側面をロードすることはできますが、実際に実行すると、環境全体をロードするコストは、ActiveRecord 自体をロードするだけにとどまりません。確かに、ActionMailer やいくつかのサイド ビットなどの側面を含めないこともできますが、それによって多くのメリットが得られるとは思えません。

代わりに私が提案するのは、やりたくないと言ったようにランナー/コンソールを実行することですが、毎回ブートストラップするのではなく、一度に1000回ではなく1000回実行するようにバッチ処理を試みます。たくさんありますこのスタイルを使用するプロジェクトの中で、例が必要な場合は、いくつかのバルク メーラーが思い浮かびます。DJ (delayed_job) は、環境スタックを使用して将来のある時点でこのコードを実行する必要があることをデータベースに少し保存することで同様のことを行いますが、できる限りまとめてバッチ処理しようとするため、それから勝つことができます。

もう 1 つのオプションは、永続的なミニレール アプリを可能な限り削除して、メモリ使用量を抑えてリクエストをリッスンし、必要なときに入札を実行できるようにすることです。これによりメモリが増えますが、ブートストラップのレイテンシは本質的に無効になります。

最後に、後付けとして、これは Postgres の優れた使用方法です。

于 2009-11-18T20:50:15.653 に答える