Java Virtual Machine • Ruby implementation fi rst, JVM language second • Many bene fi ts from JVM ecosystem • Ruby code should "just work" • Different extension API, no forking, parallel threads • https://www.jruby.org/
3.1 compatible, 98% of language specs passing • Nearly complete core + stdlib features from 2.7, 3.0 and 3.1 • JRuby 9.3 (Ruby 2.6 compat) • Maintenance through 2023 as needed • Compatibility before performance! • Now we can refocus on optimization again
runtime • Excellent JIT, GC, concurrency, and platform support • Tens of thousands of libraries • Rich tools for monitoring, pro fi ling, debugging • "Write once, run anywhere": JRuby works on many platforms
there's many distributions out there • Java 8 supported for 9.4 and lower • Install JRuby • Recommended: system package, Ruby installer, Docker image • Download tarball/zip or Windows installer
users running Rails applications?" • Oh yes! And at large scale! • Bene fi t from the JVM, libraries, languages • Great way to scale large Rails apps today!
JRuby defaults • Couple gotchas with Rails 7, we can help • Use threads in Puma instead of workers • 2n+1 is a good rule of thumb • Make sure to increase DB connections as well • Existing app: try bundling, replace unsupported libs
ActiveRecord for JRuby needs some updates • Mostly small changes to our ActiveRecord JDBC adapter • Performance and compatibility looking good! • Couple gotchas right now but we're working through them
70.0 for Rails 7.x, etc • 70.0 in progress • sqlite, mysql working pretty well, gems are out there • sqlite: 7745 runs, 25040 assertions, 32 failures, 14 errors • postgresql needs more updates, coming soon
in a microbench may not translate to production • Two example benchmarks • railsbench, small Rails blog on SQLite, no web server, tight loop • Rails blog on MySQL, end to end through Puma
database, single thread, all in one process • No web server, no connections, just loop on requests • Good for analyzing Rails core framework performance • Not great for real-world end-to-end measurement
up • Code needs to be pro fi led, analyzed, compiled • GC needs to fi nd sweet spot for heap size, generations • Known issue, but we and JVM folks always try to improve • Pre-warm new deploys (or just accept it will start off slower) • JVM tooling to bootstrap into a warm VM
code • Your code is probably not requesting the same posts in a loop • We can make this a bit more real • Full end-to-end: Puma web server, MySQL backend • External request driver (siege) • Max out CPU (high concurrency)
threads, so we need processes • Processes duplicate runtime state and waste resources • JRuby is the answer! • Multi-threaded single process runs your entire site • Single process with solid GC uses resources better
EC2 • 40 worker processes per server • 100k-150k req/min, 50-75ms response times • Migrated app to JRuby, made more use of threading • Down to 10 xlarge, 75% cost reduction • Consistently over 150k req/min, 30ms response times
out, report issues, submit a PR! • Ongoing Rails 7 updates • Big optimization work coming in the next year • New JVM features • Native fi bers! Built-in FFI!