JRuby question -- Why is it that much slower? I'd have thought that part of the point was to take advantage of the JVM's built in optimization.
Startup time is slow because it needs to warm up the JIT. Same with Rubinius, which is mysteriously missing from most of these graphs.
Memory consumption partially depends on how much you tell the JVM to use - it'll run the garbage collector more or less aggressively to keep within that bound - default appears to be min(system memory/4, 1GB).
That's not to say it doesn't need more memory than MRI, but you should factor in the concurrent native threads allowing one process to serve many clients, and the precise compacting GC limiting memory fragmentation and associated heap bloat with long-running processes.
Question (I'll end up simultaneously googling...): if the code doesn't change between restarts, is there a way one can preserve JIT statistics, so the JVM doesn't have to rediscover hotspots? Like an RDBMS able to load custom statistics for its plan engine.
I think this guy's numbers are very suspect.
I never took the time to figure out why it is faster, but I assume that it is due to C libraries being faster for json serialization and my apps doing primarily json serialization after fetching from the database.
Edit: I should test the performance of the json libs, which would be easy to do
That said, we really need to know which flags he's running Jruby with - and which
The internet tells me that you achieve better performance with -server at the expense of a bigger start-up time penalty. Anecdotally, it takes a while for the JIT compiler to find the hotspots in your code and optimize them away.
All of this will depend on how Jruby-rails keeps code in memory, yadda yadda. Someone who actually has used Java/Jruby recently can chime in with more details.
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!
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.