使用Puma运行JRuby与最新的核磁共振成像仍然有好处吗？
我正在考虑将我们的ruby解释器更新为JRuby，因为我们必须从我们的应用程序中删除任何2.x特定语法并采用ruby 1.9.3兼容性，因此非常头疼。 哪个不是世界末日。
当运行应用程序时，我发现我们不能在群集模式下使用Puma。 问题是，鉴于过去几年MRI的所有修复和变化，“真实线程”仍然有效的好处是什么？
更新
为了使其更加客观，问题是，“最新版本的MRI是否否定了采用JRuby来实现本机线程为您提供的相同优势的必要性？”
最新版本的MRI是否无需采用JRuby来实现本机线程为您提供的相同优势？
答案是不。 它不会否定需求，它取决于您在其他答案中提到的应用程序。
此外，JRuby不允许您在群集模式下运行，但这对您的问题来说并不是真正的问题，因为它是multithreading并行的。 只需在单模式下运行，即可根据需要使用多个线程。 它应该是完美的，如果不是更轻便的话。
让我给你一些参考，提供更多的见解，让你进一步挖掘。
这个答案讨论了MRI和JRuby使用Puma测试并发请求的实验（最多40个线程）。 它非常全面。
这些实验可在GitHub， MRI和JRuby上获得 。
需要注意的是，它只测试并发请求，但控制器中没有竞争条件。 但是，我认为您可以通过本文删除config.threadsafe来实现测试！ 没有太多的努力。
JRuby和MRI之间的区别在于JRuby可以并行执行代码。 MRI受GIL的限制，一次只能执行一个线程。 您可以在本文中阅读有关GIL的更多信息。 没人理解GIL 。
结果非常令人惊讶。 MRI比JRuby快。 随意改善和增加竞争条件。
请注意，两者都是multithreading的，而不是线程安全的。 区别在于MRI不能并行执行代码而JRuby可以执行。
如果实验表明MRI更快，你可能会想说我为什么回答“否”。
我认为我们需要更多的实验，特别是现实世界的应用。
如果您认为JRuby应该更快，因为它可以并行执行代码，那么原因可能是：
- 实验应该在高度并行的环境中执行，以便能够利用JRuby的潜力。
- 它可能是Web服务器本身。 也许Puma没有充分利用JRuby的全部潜力。 MRI有一个GIL，为什么它在处理请求时比JRuby快？
- 其他因素可能更深入，我们还没有发现……
真的取决于你的网络服务器的情况（你应该有最好的理解）…你认为你的生产只是在MRI下服务的情况比你可能没有那么多的并发性。 与Rubinius / JRuby相比，美洲狮的README几乎解释了你在核磁共振成像下得到的结果：
在MRI上，有一个全局解释器锁（GIL），确保一次只能运行一个线程。 但是如果你正在做很多阻塞IO（例如对Twitter之类的外部API的HTTP调用），Puma仍然可以通过允许阻塞IO同时运行来提高MRI的吞吐量（基于EventMachine的服务器，如Thin关闭此function，需要你使用特殊的库）。 你的旅费可能会改变。 为了获得最佳吞吐量，强烈建议您使用具有Rubinius或JRuby等真实线程的Ruby实现
……所以在一句话中：**你可以在MRI下有多个线程，但你没有并行性**
恕我直言这取决于您的应用程序做什么。
我在Rails应用程序上测试了MRI / YARV和JRuby。 由于应用程序所做的大部分工作是路由HTTP请求，从数据库获取，应用简单的业务逻辑并写入数据库，所以并行性不是问题。 MRI上的Puma确实处理multithreading以阻止IO操作（DB，API）。 从这个范围（图像处理，处理报告数据，调用外部API等）的任务应该可能由后台作业处理（我建议https://github.com/brandonhilkert/sucker_punch ）。
根据您的部署需求，内存消耗可能会成为一个问题，JRuby非常渴望内存。 在我的情况下几乎是2倍的内存。
如果你在Heroku上部署你的应用程序，你可能会发现你可以通过在1 dyno上同时运行2个实例来获得更大的收益。