13

Web アプリケーションのバックエンドをサポートするために使用しようとしてpython-rqいますが、新しいジョブのプッシュには非常に時間がかかります (最大 12 秒)。

enqueue_call特にシステムに接続されているワーカー プロセスの数が増加した場合 (200 以上) 、関数呼び出しの実行時にパフォーマンス ヒットが発生します。

システムは次のように機能します。

  1. フロントエンドはジョブをタスク キュー サーバーにプッシュします。これは、enqueue_call関数を使用して、実行される関数への実際の引数に加えて、引数 (timeout や ttl など) をジョブに渡します。
  2. 複数のプロセス (複数のマシンに分散) がそれぞれ UNIX の下でワーカーを実行していますscreen。ワーカーはドキュメントで提供されているパターンに従い、Worker.work()無限ループ関数を実行してキューをリッスンします。
  3. 処理中、一部のタスクは、通常、実行中の同じキューで新しいタスクを生成します。

インフラストラクチャについて:

  • このタスク キューを実行する Redis サーバーは専用です。また、永続性は無効になっています。4 GB の Rackspace サーバーで実行されています。
  • タスク キューを使用してサーバーで実行redis-benchmarkすると、ほとんどのベンチマークで平均 20000 r/s を超える結果が得られます。

このような状況で、新しいジョブのプッシュ パフォーマンスを改善するにはどうすればよいでしょうか? 使用すべきより良いパターンはありますか?

4

1 に答える 1

0

12秒？これは非常識です。

セロリの使用を考えたことはありますか？
redis-rqを使用したことはありませんが、ドキュメントに基づいて私が見たところ、多数のワーカーにはあまり適していません
通常、複数のクライアントで動作するBLPOPコマンドに基づいたRedisキューですが、実際にどれだけ処理できるかは誰にもわかりません鍵。

したがって、Celery に切り替えるか、python-rq 用の独自のタスク ディストリビューターを作成することをお勧めします。これは切り替えよりも簡単ではありません。

于 2013-03-24T01:37:10.123 に答える