4 ms·
http://www.isrubyfastyet.com/ http://www.isrubyfastyet.com/ seems to show that Rails+JRuby performance remains disappointingly bad. The memory usage is kind of
by gdeglin 13y ago
http://www.isrubyfastyet.com/ http://www.isrubyfastyet.com/ seems to show that Rails+JRuby performance remains disappointingly bad. The memory usage is kind of nuts too, not sure why it's so high.
Edit:
This page explains the high memory usage and it seems more reasonable now: https://github.com/jruby/jruby/wiki/Troubleshooting-Memory-Use https://github.com/jruby/jruby/wiki/Troubleshooting-Memory-U...
- RyanZAG 13y agoI think this would be a better benchmark than that one as it runs a more apples-apples comparison: http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=json&l=35s http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...
- teacup50 13y agoThese benchmarks are uselessly bad: - The client connections are run without concurrency, serially, on the same machine: https://github.com/brianhempel/isrubyfastyet/blob/master/runner/benchmarks/rails/requests_per_second_benchmark.rb#L16 https://github.com/brianhempel/isrubyfastyet/blob/master/run... - The JIT is only given 3 seconds to warm up: https://github.com/brianhempel/isrubyfastyet/blob/master/runner/benchmarks/rails/requests_per_second_benchmark.rb#L12 https://github.com/brianhempel/isrubyfastyet/blob/master/run... -- HotSpot kicks ass, but not after only 3 seconds of serially issued requests. - By running the tests single-threaded, they're throwing away one of the major wins of the JVM -- low overhead concurrency.