2. 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
3. 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 potential
memory 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
4. 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
9. “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.
10. 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
12. 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
13. 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"]
14. 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)
16. 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
17. 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