Rails 控制器，可以安全地分叉一个块然后返回吗？
简短而简单的问题：
fork { something_that_takes_a_few_seconds_and_doesnt_concern_the_user }
respond_to ...
是否有任何理由不在 Rails 应用程序中执行此类操作？在 PHP 中，我们目前依赖外部排队系统（如 beanstalk 或 Amazon 的 SQS）以及异步任务工作线程，该工作线程将事物从队列中拉出以在后台运行。在许多情况下，简单的叉子更适合，具体取决于任务的复杂性。
Short and simple question:
fork { something_that_takes_a_few_seconds_and_doesnt_concern_the_user }
respond_to ...
Is there any reason not to do this sort of thing in a rails app? In PHP we're currently relying on external queueing systems like beanstalk or Amazon's SQS coupled with an asynchronous task worker that's pulling things off the queue to run in the background. A simple fork would fit better in many cases, depending on the complexity of the task.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，如果您收到太多请求或者此过程花费的时间比预期长，您可以轻松地破坏您的 CPU 和内存，并且 Rails 应用程序将开始引发内存不足错误。
Rails 应用程序有许多非常简单的后台工作解决方案，例如 Resque，并且您可以在使用此类解决方案中受益匪浅一个解决方案而不是分叉，因为它总是发生在您的 web 应用程序环境之外，即使发生一些令人讨厌的事情，它也将仅限于工作计算机（而不是您的应用程序服务器）。
另外，我看到很多人说，一旦你转向虚拟化的话，内存碎片（由于产生和杀死许多进程）可能会造成损失，并使你的速度变慢。
Yes, if you get too many requests or this process takes longer than expected you can easily blast your CPU and memory and the Rails app is going to start raise out of memory errors.
There are many dead simple background workers solutions for Rails apps, like Resque, and you can benefit greatly in using such a solution instead of forking, as it would always happen out of your webapp environment and even if something nasty happens it would be confined to the worker machine (and not your application server).
Also, I've seen a lot of people saying that once you move to a virtualized word, memory fragmentation (due to spawning and killing many processes) might take their toll and make you go slower.