Nick Sieger: JRuby Performance Tweaks http://blog.nicksieger.com/articles/2007/10/25/jruby-performance-tweaks en-us 40 JRuby Performance Tweaks <p>The back&#45;story for my <a href="/articles/2007/10/25/jruby-on-rails-fast-enough">post on JRuby performance</a> is that I was actually doing some benchmarking while applying successive tweaks to the JRuby environment to see how it affected our application performance&#46; Only after running the final set of tweaks for longer numbers of requests did I notice that JRuby was catching up to MRI!</p> <p>I thought it would be interesting to point out the tweaks themselves, to reiterate the point that JRuby and the JVM give you lots of knobs to tune your application&#46; The <a href="http://pastie.caboo.se/110490">notepad of tweaks, numbers and the script used to run them is here</a>&#46;</p> <ol> <li>I started by running the application with the &#8220;out of the box&#8221; setup: JRuby 1&#46;0&#46;1&#46; I then started to apply tweaks to see how the numbers changed&#46;</li> <li>The first tweak was to turn off ObjectSpace, <a href="http://headius.blogspot.com/2007/04/what-would-i-will-i-change-about-ruby.html">which is pure overhead</a> for JRuby&#46;</li> <li>Next, I enabled <a href="http://caldersphere.rubyforge.org/jrexml">JREXML</a> since our application uses ActiveResource&#46;</li> <li>Next, I tried enabling <a href="http://headius.blogspot.com/2007/10/another-performance-discovery-rexml.html">Charlie&#8217;s discovery in the <code>rexml/source</code></a>&#46; It appears that the benefit was negated by JREXML, so I went back and ran another run with the <code>rexml/source</code> patch and without JREXML as 2a&#46; 2a gave almost as much benefit by itself as JREXML, so that&#8217;s an option if you don&#8217;t want the additional dependency, but you should measure for yourself since the performance profiles of those two fixes for XML may differ depending on the amount of XML consumed&#46; In our case it&#8217;s relatively small, a few kilobytes at most&#46;</li> <li>Next, I switched to JRuby trunk instead of 1&#46;0&#46;1&#46; Trunk has, among other improvements, a <a href="http://headius.blogspot.com/2007/09/compiler-is-complete.html">complete compiler</a>, which should allow more of the application to be translated to Java bytecode&#46;</li> <li>The last tweak for this study was to change to the &#8220;server&#8221; VM&#46; The server VM is known to take longer to warm up, but is more aggressive in the optimizations it performs&#46;</li> </ol> <p>The beauty of this exercise is that all the changes made provided small performance boosts for the application&#46; Going forward, we hope to make more of this baked&#45;in behavior (ObjectSpace off by default, possibly the rexml/source fix), but it will still help to have knowledge of and play around with <a href="http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp">the hotspot settings for the JVM</a>&#46;</p> <p>There are a few more things I&#8217;d like to try in the future: JDK 6 is reportedly a lot faster all by itself, and the <a href="http://weblogs.java.net/blog/arungupta/archive/2007/09/announcing_glas.html">standalone Glassfish gem</a> may give Mongrel a run for his money&#46; There is still plenty of work left for the impending JRuby 1&#46;1 release, so we should see the performance improvements for Rails applications running on JRuby continue to roll in&#46;</p> Thu, 25 Oct 2007 16:04:17 +0000 urn:uuid:1b736f1f-b8aa-4ab4-b64f-a94d2a25f1e2 Nick Sieger http://blog.nicksieger.com/articles/2007/10/25/jruby-performance-tweaks jruby http://blog.nicksieger.com/articles/trackback/336