1

私はDjango Webアプリケーションを持っており、バックグラウンドで動作する（または実際には開始される）タスクがいくつかあります。

アプリケーションは次のようにデプロイされます。

  • apache2-mpm-worker;
  • デーモン モードの mod_wsgi (1 プロセス、15 スレッド)。

バックグラウンド タスクには次の特徴があります。

  • 一定の間隔 (約 5 分ごと) で動作する必要があります。
  • アプリケーション コンテキストが必要です (つまり、アプリケーション パッケージがメモリ内で利用可能である必要があります)。
  • 電子メールの送信やデータベースの状態の更新など、それほど重くないタスクを実行するために、データベース アクセス以外の入力は必要ありません。

現在、この問題に対する最も単純なアプローチは、(mod_wsgi によって生成された) 既存のアプリケーション プロセスにピギーバックすることだと考えていました。タスクをアプリケーションの一部として実装し、それに HTTP インターフェースを提供することで、すべてのアプリケーションをメモリに保持している別のプロセスのオーバーヘッドを防ぐことができます。この HTTP インターフェイスに 5 分ごとにリクエストを送信する単純な cronjob をセットアップできます。アプリケーション プロセスは 15 のスレッドを提供し、タスクは非常に軽量で 5 分ごとにしか実行されないため、Web アプリケーションのユーザー向け操作のパフォーマンスが妨げられることはないと思います。

それでも...私はいくつかのオンライン調査を行いましたが、このアプローチを支持する人は誰もいません. 多くの記事では、本格的なメッセージング コンポーネント ( RabbitMQ を使用する Celery など) に基づく、より複雑なアプローチを提案しています。それはセクシーですが、私にはやり過ぎに思えます。一部の記事では、タスクを実行するスクリプトを実行する cronjob を設定することを提案しています。しかし、それもあまり魅力的ではありません。アプリケーション全体をメモリにロードし、いくつかの小さなタスクを実行し、プロセスを再び破棄する新しいプロセスを作成することになるからです。そして、これは5分ごとに繰り返されます。エレガントなソリューションのようには聞こえません。

そのため、前の段落の前の段落で説明したように、提案したアプローチについてのフィードバックを探しています。私の推論は正しいですか？(潜在的な) 問題を見落としていませんか? アプリケーションのパフォーマンスが妨げられないという私の仮定はどうですか?

4

2 に答える 2

1

特定の要件に応じて、すべてが合理的なアプローチです。

もう 1 つの方法は、WSGI スクリプトがロードされたときにプロセス内でバックグラウンド スレッドを起動することです。このバックグラウンド スレッドは、必要な作業を実行するために時々スリープおよびウェイクアップし、その後スリープに戻る可能性があります。

ただし、この方法では、バックグラウンド スレッドが実行される Django プロセスが最大で 1 つ必要であり、異なる処理がデータベースなどで同じ作業を行うことを回避します。

単一のプロセスでデーモンモードを使用すると、その基準が満たされます。マルチプロセス構成であっても、他の方法でそれを達成できる可能性があります。

于 2010-04-21T01:33:36.793 に答える
0

セロリはRabbitMQがなくても機能することに注意してください。ゲットー キュー (SQLite、MySQL、Postgres など、および Redis、MongoDB) を使用できます。これは、テストや、RabbitMQ が過剰に思える単純なセットアップに役立ちます。

http://ask.github.com/celery/tutorials/otherqueues.html (メッセージング キューとして Redis/Database で Celery を使用) を参照してください。

于 2010-04-22T13:54:43.227 に答える