jRuby

jRuby: Why?

Ruby isn’t perfect

• Some gems can create memory leaks

– esp. if they were written with native C

• Does not have kernel level threading

– Global Interpreter Lock

• Everything is an object means unnecessary processing happens when doing things like adding numbers leading to a performance hit

jRuby: So how does it fix things?

I hate writing Java…but the JVM is a work of art• Java infrastructure is virtually bulletproof

– Most mature way to deploy a web application– Enterprisey

• JVM’s garbage collector is best of breed and eliminates the potentialmemory leak issues

• JVM’s Just-In-Time compiler continually optimizes code the longer it runs making it faster

• JVM gives Ruby kernel level threading• jRuby inspects your Ruby code to see if you’re doing anything it would

prefer you didn’t…and turns it off if you’re not– Eg. If you aren’t overloading the + operator on int’s, it will convert them to

basic types instead of running as objects

• Include and use very mature Java libraries directly in your Ruby code– Significantly expands your toolbelt– Allows easy integration into existing Java environments

The Sidekiq Test

Sidekiq is a multithreaded background worker that provides tremendous concurrency benefits

Creating 1,000,000 objects in 50 concurrent threads

Ruby

jRuby

The App Server Test

CPU Usage

The App Server Test

Free Memory

The App Server Test

Latency

The App Server Test

Throughput

“Warming up the JVM”

• Important term for benchmarking

• Translation

– Run enough requests through the system for the JIT compiler to optimize the code. Code will get faster and more RAM efficient the longer it runs.

Update and Clarification

• As of this posting to Slideshare, Torquebox has a mature version 3 and a prototype version 4 that operates in a “web server only” mode. Ruby is at version 2.1.0 with dramatic improvements to memory performance with forking which allows higher concurrency.

• At this time, jruby it’s much closer. Based on chatter from the #jruby IRC channels, a major new release of both jRuby and Torquebox are expected to dramatically improve their performance thanks to recent Java updates. The expected timeline was late 2014 last I heard.

• Independent benchmarks can be found here: http://www.techempower.com/benchmarks/#section=data-r9&hw=peak&test=json

As for those benchmarks

Use Java libraries IN Ruby

require ‘java’

java_import ‘java.lang.System’

System.gc()

# Call the Java Garbage Collector

# You don’t need to do this, just an example

# More http://bbll.us/WcJZbM

JARs!

require 'path/to/mycode.jar’

# Reference as full package

Java: org.foo.department.Widget

Ruby: Java::OrgFooDepartment::Widget

# Without full package

java_import java.lang.System

version = System.getProperties["java.runtime.version"]

So, how do you use it?

Convert your application

• Switch to jRuby with RVM

• Define jRuby as your engine

• gem install jruby-lint

• Run jrlint to check Gems– Replace where needed

• Switch your database connection adapter

Then DEPLOY

• Use a Java server just like you currently use Ruby servers– Puma

– Torqbox

• OR create a .war file– Deploy anywhere Java can

• OR use a Ruby-ized Java Application Server– Trinidad (aka – Tomcat)

– Torquebox (aka – Jboss)

WHAT’S AN APPLICATION SERVER?It’s my stack in a box

Torquebox / JBoss

• Web Server• Background Jobs• Queuing• Job Scheduling• Daemon Processes• Infinispan

– faster memcached

• Pub/Sub

• Clustering– of everything

• Rolling Deployments– Across the cluster

• Load balancing– of everything

• Unique execution– Across the cluster

• Deploy multiple apps– In one cluster– Share/Separate resources– Console equivalent

Any important relationships?

• jRuby core developers

• Torquebox core developers

• Same people.

• jRuby advancements are leveraged by Torquebox first

• Torquebox is the fastest server for a reason

LET’S CONVERT YOUR APP