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

前端之家收集整理的这篇文章主要介绍了使用Puma运行JRuby与最新的核磁共振成像仍然有好处吗?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在考虑将我们的 ruby解释器更新为J Ruby,因为我们必须从我们的应用程序中删除任何2.x特定语法并采用ruby 1.9.3兼容性,因此非常头疼.哪个不是世界末日.

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

更新

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

解决方法

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,MRIJRuby上获得.

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

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

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

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

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

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

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

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

原文链接:https://www.f2er.com/ruby/269125.html

猜你在找的Ruby相关文章