使用 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)
一般来说,使用绿色线程异步运行后台任务意味着您的应用程序可以在发送邮件之前响应用户。 您不关心利用多个CPU; 您只关心将工作卸载到后台进程并尽快返回网页。
通过检查Rails文档,看起来deliver_signup_notification将阻塞足够长的时间以使邮件排队(尽管我可能是错的)。 因此,在这里使用线程可能会让您的应用程序看起来响应更快,具体取决于您的邮件程序的配置方式。
不幸的是,我不清楚 Deliver_signup_notification 是否一定是线程安全的。 在依赖它之前,我想仔细阅读文档。
另请注意,一旦请求得到处理,您就对 Rails 进程的生命周期做出假设。 许多 Rails 应用程序使用 DRb(或类似工具)将这些后台任务卸载到完全独立的工作进程上。 最简单的方法是经常更改 - 请参阅 Google 许多流行的库。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发送该电子邮件时,几乎肯定仍会应用全局虚拟机锁定,这意味着没有区别。
您不应该在请求/响应周期中启动线程。 你根本不应该启动线程,除非你可以观察它们从创建到连接的整个过程,即使这样,它所带来的麻烦也很少值得。
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.