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

Question

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

当运行应用程序时,我发现我们不能在群集模式下使用Puma.问题是,鉴于过去几年MRI的所有修复和变化,"真实线程"仍然有效的好处是什么？

更新

为了使其更加客观,问题是,"最新版本的MRI是否否定了采用JRuby来实现本机线程为您提供的相同优势的必要性？"

Answer 1

最新版本的MRI是否无需采用JRuby来实现本机线程为您提供的相同优势？

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

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

让我给你一些参考,提供更多的见解,让你进一步挖掘.

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

这些实验可在GitHub,MRI和JRuby上获得.

需要注意的是,它只测试并发请求,但控制器中没有竞争条件.但是,我认为您可以通过本文删除config.threadsafe来实现测试!没有太多的努力.

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

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

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

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

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

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

我还没有运行你的基准测试,但你可能想对它们进行一些预热; 一旦JIT有机会进入,JRuby就会大大*快*. (2认同)
@Elyasin在开始测量之前,只需向应用程序发出100多个请求.默认情况下,[JIT在50次调用方法后启动](https://github.com/jruby/jruby/wiki/JITCompiler).前两张图[这里](http://www.isrubyfastyet.com/)说明了差距; 一个温暖的JRuby VM优于一个温暖的MRI VM,虽然一个冷的MRI VM击败了一个冷的JRuby VM.但是,由于Rails应用程序往往是长期运行的,因此通常在基准测试之前通过执行预热来模拟应用程序在很长一段时间内的性能. (2认同)