Skip to content

Performance

Chad Remesch edited this page Jul 5, 2015 · 27 revisions

Below are a list of tests which will give you a rough idea of what to expect from Tribe. All tests are run on my development system (2014 Macbook Pro 13", 3.0Ghz dual core Intel i7, 16GB RAM, OS X 10.10.3).

Message Throughput

This test creates 100,000 actors, 20 counter objects, and increments each counter to 100,000. All 20 counters are incremented in parallel by passing the counter object between randomly selected actors. The goal is to maximize the use of multi-core systems.

require 'tribe/benchmark'
Tribe::Benchmark::Throughput.run

Results

Each benchmark was run 3 times:

  • MRI Ruby 2.2.2: (50611, 49633, 50011) = 50,085 messages/second (average)
  • MRI Ruby 2.2.2 with jemalloc: (57426, 57612, 57739) = 57,592 messages/second (average)
  • Jruby 1.7.20 with Java 1.8.0_31: (167630, 173025, 173175) = 171,276 messages/second (average)

Tuning

  • MRI Ruby: none
  • MRI Ruby with jemalloc: Compiled with... RUBY_CONFIGURE_OPTS=--with-jemalloc
  • JRuby: JRUBY_OPTS="-J-Xmn512m -J-Xms2048m -J-Xmx2048m -J-server"

Note: The first run with each version of Ruby was excluded in order to give the VM a chance to warm up. This had no noticable benefit for MRI, but it did have a large benefit for JRuby.

Conclusion

JRuby provided a substantial performance boost over MRI Ruby. It is recommended that you use Tribe with the latest JRuby 1.7.X and Java 8 due to its increased thread and garbage collector performance.

Based on past benchmarks, Ruby 2.2.X performs substantially better than older versions of MRI (2.0 & 2.1). Most likely this is due to the much improved garbage collector.

If you must use MRI on OSX, it is highly recommended you compile --with-jemalloc as it provides substantial improvement over the default malloc. Similar results are expected on Linux, but have not been confirmed yet.

Clone this wiki locally
You can’t perform that action at this time.