使用 Thread.new 在 Rails 上发送电子邮件
我一直在我的应用程序（ruby 1.8.7，rails 2.3.2）上发送电子邮件，如下所示 <代码> Thread.new{UserMailer.deliver_signup_notification(user)}
由于 ruby 使用绿色线程，因此这样做有任何性能优势，或者我可以使用 <代码> UserMailer.deliver_signup_notification（用户） ？
谢谢
I've been sending emails on my application (ruby 1.8.7, rails 2.3.2) like this
Thread.new{UserMailer.deliver_signup_notification(user)}
Since ruby use green threads, there's any performance advantage doing this, or I can just use
UserMailer.deliver_signup_notification(user)
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
发送该电子邮件时，几乎肯定仍会应用全局虚拟机锁定，这意味着没有区别。
您不应该在请求/响应周期中启动线程。 你根本不应该启动线程，除非你可以观察它们从创建到连接的整个过程，即使这样，它所带来的麻烦也很少值得。
Rails 不是线程安全的，也不意味着来自控制器操作。 仅从 Rails 2.3 开始，仅调度才成为线程安全的，并且仅当您在environment.rb 中使用 config.threadsafe! 打开它时。
这篇文章更详细地解释了。 如果您想异步发送消息，请使用 BackgroundRb 或其类似物。
Global VM lock will still almost certainly apply while sending that email, meaning no difference.
You should not start threads in a request/response cycle. You should not start threads at all unless you can watch them from create to join, and even then, it is rarely worth the trouble it creates.
Rails is not thread-safe, and is not meant to be from within your controller actions. Only since Rails 2.3 has just dispatching been thread-safe, and only if you turn it on in environment.rb with config.threadsafe!.
This article explains in more detail. If you want to send your message asynchronously use BackgroundRb or its analog.
一般来说，使用绿色线程异步运行后台任务意味着您的应用程序可以在发送邮件之前响应用户。 您不关心利用多个CPU； 您只关心将工作卸载到后台进程并尽快返回网页。
通过检查Rails文档，看起来deliver_signup_notification将阻塞足够长的时间以使邮件排队（尽管我可能是错的）。 因此，在这里使用线程可能会让您的应用程序看起来响应更快，具体取决于您的邮件程序的配置方式。
不幸的是，我不清楚 Deliver_signup_notification 是否一定是线程安全的。 在依赖它之前，我想仔细阅读文档。
另请注意，一旦请求得到处理，您就对 Rails 进程的生命周期做出假设。 许多 Rails 应用程序使用 DRb（或类似工具）将这些后台任务卸载到完全独立的工作进程上。 最简单的方法是经常更改 - 请参阅 Google 许多流行的库。
In general, using green threads to run background tasks asynchronously will mean that your application can respond to the user before the mail is sent. You're not concerned about exploiting multiple CPUs; you're only concerned on off-loading the work onto a background process and returning a web page as soon as possible.
And from examining the Rails documentation, it looks like deliver_signup_notification will block long enough to get the mail queued (although I may be wrong). So using a thread here might make your application seem more responsive, depending on how your mailer is configured.
Unfortunately, it's not clear to me that deliver_signup_notification is necessarily thread-safe. I'd want to read the documentation carefully before relying on that.
Note also that you're making assumptions about the lifetime of a Rails process once a request has been served. Many Rails applications using DRb (or a similar tool) to offload these background tasks onto an entirely separate worker process. The easiest way to do this changes fairly often--see Google for a number of popular libraries.
我已经使用了您的确切策略，我们的应用程序目前正在生产中运行（但 Rails 2.2.2）。 我一直密切关注它，我们的负载相对较低（平均每天发送不到 20 封电子邮件，峰值约为每天 150 封）。
到目前为止，我们还没有发现任何问题，这似乎解决了我们在使用 Google 邮件服务器时遇到的几个性能问题。
如果您急需某些东西，请尝试一下，它一直对我们有用。
I have used your exact strategy and our applications are currently running in production (but rails 2.2.2). I've kept a close eye on it and our load has been relatively low (Less than 20 emails sent per day average, with peaks of around 150/day).
So far we have noticed no problems, and this appears to have resolved several performance issues we were having when using Google's mailserver.
If you need something in a hurry then give it a shot, it has been working for us.
据我所知，它们是一样的。
They'll be the same as far as I know.