Looks like it's running with the threadsafe mode off. That would probably give JRuby an edge, as it's able to take advantage of greater thread parallelism than MRI. No idea if he's letting the JVM warm up enough either.
As far as I know, Passenger Enterprise and Puma are the only multi-platform ruby rack app servers that support multi-threaded concurrent request dispatch. There may be other jruby/java-only deployment scenarios that support concurrent request dispatch.
Without concurrent request dispatch, jruby's hypothetical greater thread parallelism is unlikely to effect requests-per-second benchmarks. Also, the benchmarking test would have to be willing to issue requests concurrently!
> Without concurrent request dispatch, jruby's hypothetical greater thread parallelism is unlikely to effect requests-per-second benchmarks. Also, the benchmarking test would have to be willing to issue requests concurrently!
That's a good point.
That said, JRuby would most likely benefit from a concurrent test, as the thread-per-request model of JRuby can scale much higher than the process-per-request model which is used a lot in the MRI world.
Yes, that's what I said, _if_ you have an app server that supports concurrent request handling. If you are deploying a JRuby app with thin or unicorn or the free version of passenger -- you don't get multi-threaded concurrent request handling.
As far as I know, Passenger Enterprise and Puma are the only multi-platform ruby rack app servers that support multi-threaded concurrent request dispatch. There may be other jruby/java-only deployment scenarios that support concurrent request dispatch.
Without concurrent request dispatch, jruby's hypothetical greater thread parallelism is unlikely to effect requests-per-second benchmarks. Also, the benchmarking test would have to be willing to issue requests concurrently!