The JIT's kicking in is governed by the request count, not the request rate, so this claim is meaningless.

To be precise, in Java 8, if the JIT is not heavily loaded and the code cache has space, then for a method with no loops, compilation will happen when the invocation count exceeds the Tier3InvocationThreshold:

http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/2b2511bd...

On my machine, with 1.8.0_11-b12, that is 200.

Wow are you seriously comparing mri with jvm that receivee billions of dollars and significant manpower investments and is fundamentally different from.mri?

Yeah, this is why if you want to serve more than 200rps on a dedicated box you pick something other than Ruby in 2016.

This is a t2.micro instance (regardless of the hostname) running Ruby:

http://imgur.com/a/EGMt4

Running what, a bare metal rack app returning an empty response and doing no real work? All requests are not made equal, which is why these RPS judgements are pretty silly unless we define the exact request.

There's the TechEmpower benchmarks for that though. And you can't deny Ruby is among the worst there.

He is comparing one VM to another. What is the problem? Even BEAM and other VMs outperform mri.

Even Beam really ?...another one that received an insane amount of money in funding. There IS virtually nothing that prevents mri from becoming at least as fast as v8.

Again you are comparing apples to oranges.

Alright, I see that we are going from billions to millions. Soon we are going to hit a VM that got just few thousand in funding and still outperforms MRI. Please stop using lack of funding as justification for something that is subpar compared to another thing in the same category. Again, we are talking about VMs, so the comparison is apple to apple. One apple is more shiny than the another, I agree, the reason might be funding, I agree again.