升级Rails 2.3至5.2及JRuby 1.7至9.2后性能衰退问题咨询

Hey there, let's break down your questions and tackle that performance drop head-on—upgrading legacy JRuby apps can be tricky, but there are plenty of fixes and best practices to get you back up to speed.

1. Is JRuby still suitable for Rails 5, and are there users achieving good performance? #

Absolutely—JRuby is fully compatible with Rails 5.x, and many enterprise-grade applications (especially those relying on Java integrations like yours) run it successfully with solid performance. The performance hit you're seeing is almost certainly tied to the jump from JRuby 1.7 (Ruby 1.8 compatibility) to JRuby 9.2.x (Ruby 2.x compatibility):

• JRuby 9.x uses a completely rewritten bytecode generator and runtime, which has different optimization characteristics than 1.7.
• Rails 5's view layer introduced several changes (like improved template caching and new rendering logic) that interact differently with JRuby's runtime.
• JIT warmup: JRuby 9.x's JIT compiler needs time to optimize frequently called methods—if your app isn't properly warmed up in production, you'll see slower initial requests.

Many teams have resolved similar issues by tuning JRuby's runtime and Rails configuration, so this is definitely solvable.

2. Recommended JDK version for JRuby? #

Stick with OpenJDK 8 or OpenJDK 11 (LTS versions). Here's why:

• JRuby 9.2.x is heavily optimized for these two LTS releases—they've been tested extensively with JRuby's runtime and JIT compiler.
• Newer JDKs (like 13+) introduce newer GC algorithms (ZGC, Shenandoah) and bytecode changes that JRuby 9.2.x doesn't fully optimize for yet, which explains why you saw slower performance with OpenJDK 13.
• If you want to squeeze out a little extra performance, you can try Oracle JDK 8 alongside OpenJDK 8—some teams report minor gains in specific workloads, but the difference is usually minimal.

3. JRUBY_OPTS optimization suggestions #

Your current settings are a good start, but let's tweak them for better performance, especially around JIT and GC:

JRUBY_OPTS="-J-Xmx4g -XX:ReservedCodeCacheSize=512M -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+UseStringDeduplication -XX:+TieredCompilation -J-Djruby.reify.invokedynamic=true --jit.enabled=true --jit.threshold=10 --jit.max=3000"

Let's break down the key additions:

• -XX:+UseG1GC -XX:MaxGCPauseMillis=200: Switches to G1GC, which is better at handling the short-lived objects generated during view rendering, with more predictable pause times.
• -XX:+UseStringDeduplication: Reduces memory overhead from duplicate strings (common in view templates) and lowers GC pressure.
• -XX:+TieredCompilation: Works with JRuby's JIT to optimize frequently called methods faster.
• -J-Djruby.reify.invokedynamic=true: Enables invokedynamic support, which drastically speeds up Ruby method calls (a big win for view rendering logic).
• --jit.enabled=true --jit.threshold=10 --jit.max=3000: Forces JIT to kick in earlier (after 10 calls instead of the default) and compile more methods, which helps warm up your app faster.
• Note: --server is enabled by default in JRuby 9.x, so you can remove it from your opts.

4. Better performance analysis methods for JRuby on Rails #

Datadog and JVisualVM are great, but they often miss Ruby-level details in JRuby apps. Try these tools to pinpoint the slow parts of your view rendering:

• JRuby's Built-in Profiler:
  Run your app with the profiler enabled to get Ruby-specific call stacks:

  jruby --profile -S rails s
  

  You can also enable it programmatically in production (temporarily) to capture detailed reports:

  # config/initializers/profiler.rb
  if Rails.env.production?
    require 'jruby/profiler'
    JRuby::Profiler.start
    at_exit do
      profile_data = JRuby::Profiler.stop
      File.write('/tmp/jruby_profile.txt', profile_data.pretty_print)
    end
  end
  

  This will show you exactly which Ruby methods (including ERB template evaluation, partial rendering, etc.) are eating up time.

• RubyProf (JRuby-Compatible):
  Install the JRuby-friendly version of RubyProf and use it to generate detailed Ruby-level flame graphs or call trees:

  gem install ruby-prof
  

  Add a middleware to profile specific requests, or wrap heavy view logic in a profiling block to isolate slow templates.

• JProfiler:
  While it's a commercial tool, JProfiler excels at mixing Ruby and Java call stacks. It can show you when view rendering is blocked by GC, or which specific ERB compilation steps are taking too long—perfect for your scenario where database time is constant but view time is spiking.

• Targeted View Logging:
  Enable detailed ActionView logging in config/environments/production.rb:

  config.action_view.logger.level = :debug
  

  This will log the exact time taken to render each partial and template, so you can quickly isolate which part of your "heavy" page is causing the slowdown. For even more detail, add manual timing to suspect templates:

  <% start = Time.now %>
  <!-- Your template logic here -->
  <% Rails.logger.debug "Rendered this section in #{(Time.now - start)*1000}ms" %>
  

内容的提问来源于stack exchange，提问作者Alexander Malfait