ruby - 与使用 Puma 的最新 MRI 相比，运行 JRuby 是否还有优势？

Question

我正在考虑将我们的 ruby​​ 解释器更新为 JRuby，这非常令人头疼，因为我们不得不从我们的应用程序中删除任何 2.x 特定语法并求助于 ruby​​ 1.9.3 兼容性。这不是世界末日。

当运行该应用程序时，我发现我们无法在集群模式下使用 Puma。问题是，鉴于过去几年对 MRI 的所有修复和更改，拥有“真实线程”的好处是否仍然有效？

更新

为了使这个更客观，问题是“最新版本的 MRI 是否不需要采用 JRuby 来实现 native 线程为您带来的相同好处？”

Answer 1

Does the latest version of MRI negate the need to adopt JRuby to achieve the same benefits that native threads give you?

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

此外，JRuby 不允许您以集群模式运行，但对于您的问题而言这并不是真正的问题，因为它是多线程和并行的。只需在单模式下运行，并根据需要使用尽可能多的线程。它应该非常好，如果不是更轻的话。

---

让我给你一些引用，让你有更多的洞察力，让你深入挖掘。

这answer讨论使用 Puma(最多 40 个线程)使用 MRI 和 JRuby 测试并发请求的实验。内容很全面。

实验可在 GitHub 上获得，MRI和 JRuby .

需要注意的是它只测试并发请求，但在 Controller 中没有竞争条件。但是，我认为您可以实现本文 Removing config.threadsafe! 中的测试无需太多努力。

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

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

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

---

如果实验表明 MRI 速度更快，您可能会想说为什么我回答“否”。

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

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

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