Search code examples
rubyjrubypumamri

Are there still benefits to running JRuby vs. the latest MRI with Puma?

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.

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?

update

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?"

Solution

  • 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.

    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.

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

    The experiments are available on GitHub, MRI and JRuby.

    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.

    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.

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

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

    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.

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

    • 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...