使用Puma与最新的MRI相比，运行JRuby仍然有好处吗? [英] Are there still benefits to running JRuby vs. the latest MRI with Puma?

问题描述

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

I'm considering updating our ruby interpreter to JRuby, it's been quite a headache because we've had to remove any 2.x specific syntax from our app and resort to ruby 1.9.3 compatibility. Which isn't the end of the world.

当需要运行该应用程序时，我发现我们无法在集群模式下使用Puma.问题是，考虑到过去几年对MRI的所有修复和更改，使用真实线程"的好处是否仍然有效?

When it came time to run the app, I found out that we cannot use Puma in clustered mode. The question is, given all the fixes and changes to MRI in the past few years, are the benefits of having "real threads" still valid?

更新

要使这个目标更加客观，问题是:最新版的MRI是否否定了采用JRuby来实现本机线程给您带来的相同好处的需要?"

To make this more objective, the question is, "Does the latest version of MRI negate the need to adopt JRuby to achieve the same benefits that native threads give you?"

推荐答案

MRI的最新版本是否否定了采用JRuby的需要? 达到本机线程给您的相同好处?

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

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

The answer is no. It does not negate the need, and it depends on your application as mentioned in other answers.

此外，JRuby不允许您在集群模式下运行，但是对于您的问题，这并不是一个真正的问题，因为它是多线程和并行的. 只需在单模式下运行所需数量的线程即可.即使不是更轻巧，它也应该很好.

Also, JRuby does not allow you to run in cluster mode, but that is not really a problem in regards to your question, because it is multithreaded and parallel. Simply run in Single mode with as many threads as you need. It should be perfectly fine, if not even more lightweight.

让我给您一些参考，这些参考可以提供更多的见识并允许您进一步深入研究.

Let me give you some references that give more insight and allow you to dig further.

此答案讨论了使用MRI和JRuby使用Puma(最多40个线程)测试并发请求的实验.非常全面.

This answer discusses experiments with MRI and JRuby testing concurrent requests using Puma (up to 40 threads). It is quite comprehensive.

可在GitHub上进行实验， MRI 和

The experiments are available on GitHub, MRI and JRuby.

需要注意的是，它仅测试并发请求，而在控制器中没有竞争条件.但是，我认为您可以根据本文删除config.threadsafe来实施测试！，无需太多的努力.

The caveat is that it only tests concurrent requests, but does not have a race condition in the controller. However, I think you could implement the test from this article Removing config.threadsafe! without too much effort.

JRuby与MRI的区别在于JRuby可以并行执行代码. MRI受GIL限制，一次只能执行一个线程.您可以在本文中阅读有关GIL的更多信息没人理解GIL .

The difference between JRuby and MRI is that JRuby can execute code in parallel. MRI is limited by the GIL and only one thread at a time can be executed. You can read more information about the GIL in this article Nobody understands the GIL.

结果非常令人惊讶. MRI比JRuby快.随时改善和增加比赛条件.

The results are quite surprising. MRI is faster than JRuby. Feel free to improve and add race conditions.

请注意，它们都是多线程的，并且不是线程安全的.真正的区别在于MRI无法并行执行代码，而JRuby可以并行执行代码.

Note that both are multi-threaded and not thread safe. The difference really is that MRI cannot execute code in parallel and JRuby can.

如果实验表明MRI更快，您可能会想说为什么我回答否".

You might be tempted to say why I answer "No" if the experiment shows that MRI is faster.

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

I think we need more experiments and in particular real world applications.

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

If you believe that JRuby should be faster because it can execute code in parallel then reasons could be:

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

• The experiments should be executed in a highly parallel environment to be able leverage the potential of JRuby.
• It could be the web server itself. Maybe Puma does not leverage the full potential of JRuby. MRI has a GIL, so why is it faster than JRuby in handling requests?
• Other factors might be relevant that are more in depth and we did not discover yet...

这篇关于使用Puma与最新的MRI相比，运行JRuby仍然有好处吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！