
Discussion of JVM performance from JRuby/Clojure creators - bgray
http://groups.google.com/group/jvm-languages/browse_thread/thread/2c10bde4b9985086
======
old-gregg
I have been curious about JRuby for a long time, and relatively recently I got
a chance to work on a JRuby-powered Rails application that hits a database,
uses external Java APIs and serves pages.

The experience has been miserable: the "warm-up problem" is so pronounced that
development reminds me of my C++ days when I had to compile my code. Rake
tasks are slow as hell. Running unit tests has been so painful that we hacked
Rails to run tests via Web interface. Memory consumption is through the roof:
JVM-based Ruby eats (or should I say wastes?) about 2-3x times more RAM that
RubyEE 1.8.6

You keep hearing RAM is cheap, but for small startups no it isn't - just look
at EC2/SliceHost/Linode prices, and 1GB instances aren't going to cut it if
you're running this pig (JVM) doing anything non-trivial.

Moreover, accessing Java classes from JRuby isn't nearly as smooth as using
something like Closure. Ruby strings aren't Java strings and it applies to
arrays, hash tables, everything. Even importing JARs isn't that trivial.
Moreover, your Ruby code which consumes Java libs looks more or less like Java
in a Halloween costume. NOT FUN.

The bottom line: yes, Rails on JRuby is about twice as fast (in our
application) but you take a shocking hit to your workflow by the startup lag
and you pay with an increased RAM wastage by JVM when you deploy.

Next time I am needing some Java libraries in a Rails app, I am hosting an
instance of Tomcat and exposing that library via a simple REST service using
plain Java.

~~~
donw
My current project is JRuby on Rails, so I wanted to inject my few cents, and
also to ask what your long-term experiences with the platform were.

Rake tasks are definitely slow; you have to wait a few seconds for them to
complete, which overall sucks. A lot. If anything, this is the one thing that
has pushed me to thinking about using MRI again. Nailgun is supposed to help a
lot here, and since JRuby 1.4.0 was recently released, I'll be giving NG a go
and seeing what the improvement is for common rake tasks.

RAM hasn't been a big problem for me. The JVM _does_ use more RAM than MRI,
but it also seems to do a better job of managing it. I've never had an out-of-
memory error, and the nastiest benchmarks I could throw against my code (a few
hours' worth of solid requests) don't jack the JVM above around 200M of RAM,
and that's with an embedded Solr server for indexing/searching. BUT... we
haven't done a fully public beta yet, just the 'friends and family' version.
So I could be talking out of the wrong orifice here.

You get real threading, which makes setting up a job scheduler a lot easier,
and lets you run a multithreaded Rails server.

The performance is quite good when compared to the 1.8.7 MRI.

Accessing Java classes isn't as nice as Closure/Groovy, but that's to be
expected. Closure and Groovy were designed from the ground up to use Java
classes as their foundation, and Ruby... wasn't. Even so, JRuby does a decent
job of autoboxing most of the time with strings and arrays, and I've had only
a few speedbumps when using Java classes in JRuby.

Loading JARs seems to work fine with 'require' for me; what problems have you
run into?

What is the long-term memory use for your application like; e.g., does it grow
hugely over time, or remain relatively stable after the JVM warmup?

What JVM/JRuby are you using?

Other than startup slowness, what other issues have been problems for you?

~~~
old-gregg
Our application is a data cruncher, it's not a public web site, and our
controllers/views are just a GUI to control/monitor the process.

Memory usage shuts up to 700-800MB per Rails instance but it stays there
regardless of how many documents we put through the pipeline.

Also our migrations stopped working in test environments - JDBC db adapter
would "reset" itself back to mysql MRI gem ignoring database.yml. On CentOS it
would happen with all environments, not just test. We were never able to
figure out where/how this happens due to extremely dynamic/"magic" nature of
AR and Ruby in general, so we're using MRI just to run migrations and we moved
to Ubuntu in production to keep JRuby/JDBC happy

But my biggest objection to using JRuby in the future is that it's easier to
use Java for accessing Java libraries, i.e. using JRuby simply because you
need some Java-based OCR package is simply not worth it - my advice would be
to use Java to access that API and then interop with MRI somehow, I would do
it via HTTP-based REST API between Rails/MRI process and Tomcat-hosted JVM.

~~~
seunosewa
You can limit the JVM heap size.

------
pohl
_This is something that might be a good candidate for openjdk and/or icedtea.
The only problem is the build seems to be regularly broken in the repository.
- Andrew Oliver_

I'm surprised that a project that large doesn't use something like tinderbox
or cruise control.

