当运行应用程序时,我发现我们不能在群集模式下使用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并发请求的实验.它非常全面.
需要注意的是,它只测试并发请求,但控制器中没有竞争条件.但是,我认为你可以毫不费力地从这篇文章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快？>其他因素可能更深入,我们还没有发现……