1

Passenger の MRI Ruby と Rails 3.2 で、スレッド セーフを考慮して設計されていないアプリを実行している大きなプロジェクトがあり、このアプリは DelayedJob を介してメーリングを処理し、データベースはこれに多額の費用を支払っています。

sidekiq railscast http://railscasts.com/episodes/366-sidekiqには、考えられるいくつかの問題が記載されています。

  1. データベース接続制限 (スレッドプール 1 を使用する場合、データベース接続制限は 2 倍にする必要があります)
  2. スレッドセーフ (これはおそらくショーストッパーです)
  3. 繊維安全？これはARの問題ですか？

したがって、質問は次のとおりです。

  1. メール生成がパッセンジャー プロセス内のスレッドで動作するように、大きなプロジェクトをスレッド セーフにすることは、どの程度実行可能でしょうか? (郵送は AR に依存するほど複雑です)
  2. sidekiq を使用する場合の同じ質問、「sidekiq を使用してメール生成が機能するように、大きなプロジェクトをスレッドセーフにすることはどの程度実行可能ですか? (メールは AR に依存するほど複雑です)」
  3. データベース接続の制限とスレッドセーフの問題以外に、他に考慮すべきこと、または私が予見できなかったあまり明白でない問題はありますか?
4

1 に答える 1

1

ここでいくつかのものを混同していると思います。

sidekiq を使用したことはありませんがthread_safe!、Rails アプリケーションで使用するために有効にする必要はないと思います。

私の知る限り、これはリクエスト処理がロックを持つか、thread_safe にロックがないためです! モードであるため、Rails プロセスは複数のリクエストを並行して処理できます。

sidekiq を使用する場合、それは気にする必要はありません。E-Mail-Processing コードだけがスレッドセーフである必要があります。ただし、その質問に答えることができるのはプロジェクトのメンテナーだけです。

于 2013-12-15T11:35:59.717 に答える