使用Puma运行JRuby与最新的核磁共振成像仍然有好处吗？

Question

我考虑将我们的ruby解释器更新为JRuby，因为我们必须从我们的应用程序中删除任何2.x特定语法并使用ruby 1.9.3，所以非常头疼。兼容性。这不是世界末日。

当运行应用程序时，我发现我们不能在群集模式下使用Puma。问题是，鉴于过去几年中MRI的所有修复和变化，有真正的线程＆＃34;还有效吗？

更新

为了使这个更客观，问题是，＆＃34;最新版本的MRI是否否定了采用JRuby来实现本机线程给你的相同好处的必要性？＆＃34;

Answer 1

  

最新版本的MRI否定了采用JRuby的必要性   实现本机线程给你的相同好处？

答案是否定的。它并没有否定需要，它取决于你在其他答案中提到的应用程序。

此外，JRuby不允许您在群集模式下运行，但这对于您的问题并不是真正的问题，因为它是多线程并行的。 只需在单一模式下运行，即可根据需要使用多个线程。它应该是完美的，如果不是更轻便的话。

让我给你一些参考资料，提供更多见解，让你进一步挖掘。

这answer讨论了使用Puma（多达40个线程）测试并发请求MRI和JRuby的实验。它非常全面。

实验可在GitHub，MRI和JRuby上找到。

需要注意的是，它只测试并发请求，但控制器中没有竞争条件。但是，我认为您可以毫不费力地从本文Removing config.threadsafe!开始实施测试。

JRuby和MRI之间的区别在于JRuby可以并行执行代码。 MRI受GIL的限制，一次只能执行一个线程。您可以在本文Nobody understands the GIL中阅读有关GIL的更多信息。

结果非常令人惊讶。 MRI比JRuby快。随意改善和增加竞争条件。

请注意，两者都是多线程的，而不是线程安全的。区别在于MRI不能并行执行代码而JRuby可以。

你可能想说我为什么回答＆＃34;否＆＃34;如果实验表明MRI更快。

我认为我们需要更多的实验，特别是现实世界的应用。

如果您认为JRuby应该更快，因为它可以并行执行代码，那么原因可能是：

• 实验应该在高度并行的环境中执行 能够利用JRuby的潜力。
• 它可能是Web服务器本身。也许Puma没有充分利用JRuby的全部潜力。 MRI有一个GIL，为什么它在处理请求时比JRuby快？
• 其他因素可能更深入，我们还没有发现......

Answer 2

真的取决于您使用网络服务器的情况（您应该对此有最好的了解）...您认为您的生产只是在MRI下服务的情况比您可能没有那么多的并发性。 puma的README几乎解释了你在MRI下与Rubinius / JRuby相比得到的东西：

在MRI上，有一个全局解释器锁（GIL），确保一次只能运行一个线程。但是，如果您正在进行大量阻止IO（例如对Twitter等外部API的HTTP调用），Puma仍然可以通过允许阻塞IO同时运行来提高MRI的吞吐量（基于EventMachine的服务器，如Thin）关闭此功能，要求您使用特殊库）。你的旅费可能会改变。为了获得最佳吞吐量，强烈建议您使用Ruby实现和真实线程，如Rubinius或JRuby

...所以在一句话中：**你可以在MRI下有多个线程，但你没有并行性**

Answer 3

恕我直言取决于你的申请是做什么的。

我在Rails应用程序上测试了MRI / YARV和JRuby。 由于应用程序所做的大部分工作是路由HTTP请求，从DB获取，应用简单的业务逻辑并写入数据库，并行性不是很大的问题。 MRI上的Puma确实处理多线程以阻止IO操作（DB，API）。那些不受此范围影响的任务（图像处理，处理报告数据，调用外部API等）应该可以由后台作业处理（我建议https://github.com/brandonhilkert/sucker_punch）。

根据您的部署需求，内存消耗可能是一个问题，JRuby非常渴望内存。在我的情况下几乎是2倍的内存。

如果您在Heroku上部署应用程序，您可能会发现，通过在1 dyno上同时运行2个实例，您可以获得更大的收益。