ruby-on-rails - Thread.new を使用してレール上でメールを送信する

Question

このようにアプリケーション（ruby 1.8.7、rails 2.3.2）でメールを送信しています Thread.new{UserMailer.deliver_signup_notification(user)}

ルビーはグリーンスレッドを使用するため、これを行うとパフォーマンス上の利点があります UserMailer.deliver_signup_notification(user) 。

ありがとう

Answer 1

グローバルVMロックは、その電子メールの送信中にほぼ確実に適用されます。つまり、違いはありません。

要求/応答サイクルでスレッドを開始しないでください。作成から参加までスレッドを監視できない限り、スレッドを開始しないでください。それでも、スレッドが作成する問題に見合う価値はほとんどありません。

Railsはスレッドセーフではなく、コントローラーアクション内からのものではありません。Rails 2.3がスレッドセーフであるため、environment.rbでconfig.threadsafe！を使用してオンにした場合にのみ発生します。

この記事では、より詳細に説明します。メッセージを非同期で送信する場合は、BackgroundRbまたはそのアナログを使用してください。

Answer 2

私はあなたの正確な戦略を使用しました、そして私たちのアプリケーションは現在本番環境で実行されています（しかしレール2.2.2）。私はそれを注意深く監視しており、負荷は比較的低くなっています（1日あたりの送信メール数は平均20未満で、ピークは1日あたり約150です）。

これまでのところ問題はありません。これにより、Googleのメールサーバーを使用したときに発生していたいくつかのパフォーマンスの問題が解決されたようです。

急いで何かが必要な場合は、それを試してみてください、それは私たちのために働いています。

Answer 3

一般に、グリーン スレッドを使用してバックグラウンド タスクを非同期で実行すると、メールが送信される前にアプリケーションがユーザーに応答できるようになります。複数の CPU を利用することについて心配する必要はありません。作業をバックグラウンド プロセスにオフロードし、できるだけ早く Web ページを返すことだけに関心があります。

また、Rails のドキュメントを調べると、deliver_signup_notification はメールをキューに入れるのに十分な時間ブロックするようです (私が間違っているかもしれませんが)。したがって、ここでスレッドを使用すると、メーラーの構成方法によっては、アプリケーションの応答性が向上するように見える場合があります。

残念ながら、deliver_signup_notification が必ずしもスレッドセーフであることは明らかではありません。それに頼る前に、ドキュメントを注意深く読みたいと思います。

また、リクエストが処理された後の Rails プロセスの存続期間について仮定していることにも注意してください。DRb (または同様のツール) を使用してこれらのバックグラウンド タスクを完全に別のワーカー プロセスにオフロードする多くの Rails アプリケーション。これを行う最も簡単な方法は、かなり頻繁に変更されます。よく使われているライブラリについては、Google を参照してください。

Answer 4

私が知る限り、それらは同じです。