The Fastest Ruby Profiler is a Java Profiler

Recently we announced that JXInsight can execute 1 billion instrumented Java method calls per second once the multi-resource (hotspot) strategy based metering runtime determines a particular method is a non-hotspot. So I was curious to see how our JRuby-to-Ruby cross language profiling extension faired with such optimizations as our probes technology is not in anyway tied to metering just named Java code execution constructs. The good news is that our technology can drop the overhead so low that it even out-performs no-op instrumentation calls in Ruby itself which means we are faster than any Ruby language based profiling or benchmarking solution (naturally when executed on the Java platform – JRuby VM).

Here is the Ruby micro-benchmark I used to determine the above.

Here is a chart showing the average time reported by multiple executions of the run method without and with our probes based instrumentation. Our instrumentation overhead is just over 15% but that is 15% on a method, call, that does nothing. Effectively our overhead is just under 15 nanoseconds for non-hotspots.

The overhead incurred in the instrumentation and measurement of fine grain method executions, which dominate the execution profile of most web applications, is a key performance indicator (KPI) for any enterprise performance management and monitoring solution.

Here is a partial screenshot of the resulting resource metering in our application management console. Note the strike-through on the call method indicating the associated instrumentation has been disabled following the execution of 1000 probe firings and the determination by the hotspot metering strategy that the named probe, Object.call, is a non-hotspot.

To determine the best (if not impossible) time a Ruby based profiling solution could do I added both a before and after method call to the call method which is typical of how most dynamic instrumentation agents work across various languages and runtimes. Both methods do nothing.

Here is a revised chart with the average execution time for the above manual instrumentation added. JXInsight is 3 times faster than a Ruby solution that does nothing.

Note: Disabling our hotspot metering strategy and comparing the performance with a version having a callout to Benchmark.measure() JXInsight is more than 15 times more efficient. Moving to JRuby has many advantages for production applications both in terms of the raw speed of the runtime itself and the supporting management and monitoring tools.

Hardware
Model Name: MacBook Pro
Model Identifier: MacBookPro5,1
Processor Name Intel Core 2 Duo
Processor Speed: 2.53 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 6 MB
Memory: 4 GB
Bus Speed: 1.07 GHz

JRuby
jruby 1.3.1 (ruby 1.8.6p287) (2009-06-15 2fd6c3d)

Runtime
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03-223)
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-92, mixed mode)


Cross Language Profiling with JXInsight – JRuby-to-Ruby

Today we have delivered a new early access build of JXInsight 5.7 which includes a JRuby-to-Ruby performance monitoring (profiling) solution making our Probes technology the first cross JVM language resource metering and billing solution – all within the same JVM.

This capability is achievable because in the design of the probes runtime we made the decision to not in anyway tie the instrumentation or measurement to a specific execution construct instead the probes runtime deals with cost centers (hierarchical named groups) which can represent a Java package, class, method, as well as a Ruby module, class, method or operator.

In fact other than a few utility methods in the Probes Open API to convert from a Java class or method to a group (name) the resource metering runtime is unaware of what groups actually represent. You could very easily map the probes to organizational departments and business units even users. 

To demonstrate the power of our approach I am going to use the standard hello world implementation in Ruby. 

With a Java code profiler (which JXInsight can be configured to act as) and running the Ruby code listed below we get the following call (track) tree output. Not very intuitive and the Ruby code (the execution context) is completely lost amongst the actual JRuby runtime call processing. 

Using our new jruby-to-ruby probes extension the same extension results in the following call (track) tree. The contextual probes extension reports the JRuby call execution in terms of Ruby modules, classes, and methods. 

It is even possible to combine both the standard profiling extension with the jruby-to-ruby contextual probes extension within the same managed runtime providing a pretty good insight into the JRuby execution engine (VM) in the context of a Ruby application.

It is also worth noting that all our probes providers (strategy, billing, charges, tracking, management, logging, tagging,…) that dynamically enhance the underlying bare-metal probes provider are also available to Ruby applications without change.

To the JXInsight Probes runtime and application management console tooling there is simply no distinction between a Java or Ruby application deployed in a managed runtime. This means Ruby application run by the JRuby VM get straight out-of-the box support for:

• Multi-Resource Metering
• Custom and Cost Meters
• Production-Ready Metering Strategies
• Resource Usage and Cost Tracking, Charging and Billing
• JMX and Logging Integration
• Cluster-Wide Aggregated Monitoring
• Metrics Integration
• Dynamic Tagging
• Offline Analysis (Inspections) and Annotation

http://www.jinspired.com/products/jxinsight/new-in-5.6.html