Twitter move to Java

Hugh Brock hbrock at redhat.com
Fri Nov 16 22:13:14 UTC 2012


On Fri, Nov 16, 2012 at 09:50:08PM +0100, Justin Clift wrote:
> On 16/11/2012, at 3:28 PM, Michal Fojtik wrote:
> <snip>
> > So I did a quick test yesterday night (or today morning ;-) where I tried
> > to use TorqueBox to run Deltacloud API and then do a benchmark using 'ab'
> > command (1000 request, concurrency set to 5) and I got interesting results:
> > 
> > 1. Deltacloud API works like a charm on jRuby (no problem, no exceptions, ...)
> > 2. The performance is 2x better with jRuby than using MRI
> > 3. Using MRI with 'thin' reveals that 5% of requests just failed without any reason,
> >   where using jRuby all request were served properly.
> > 4. The memory used by both are almost the same (well JVM use a bit more memory, but
> >   at least it does not grow ;-)
> > 
> > There are two drawbacks that I observed:
> > 
> > 1. The boot time of JVM (jRuby) is a bit longer than MRI - but that is not an issue.
> > 2. There is no code reloader for Sinatra in Torquebox (at least I tried to find one
> >   but no luck)
> > 
> > So to wrap this up, I'm very surprised by the jRuby performance and also by compatibility
> > between MRI and jRuby (1.7.0).
> 
> 
> Do you reckon it's worthwhile for the Aeolus Release Cabal to look into having
> Torquebox be a "supported" upstream platform for Aeolus in a future release?
> 
> Obviously not near term, but down the track if/when it makes sense.
> 
> Regards and best wishes,
> 
I think this is a Tech Cabal matter to start with. To explain why I'll
restate what I said on IRC earlier re jruby/torquebox:

1. Torquebox and jruby are awesome and I would love to support
them. I've never heard a single negative report about compatibility and
performance and I think it would be a huge win.

2. However we have to be really careful that our source code remains
compatible with a bog-standard Ruby environment (i.e. MRI + standard
rubygems) or we will have undone all the hard work we've done making our
upstream palatable to normal Ruby developers. To be specific, any gem
with c extensions will not (by default) work in torquebox, for obvious
reasons. We would have to make sure that any torquebox services we use
are pluggable such that our code will use native Ruby alternatives when
we're not running in Torquebox.

3. I've been told that these kinds of compatibility problems are
lessening, and the fact that Charles, bobmcw, and mgoldmann are awesome
and will be anxious to help us succeed is a point in torquebox/jruby's
favor.

4. We will need to think about how to deal with production deployments
when running on torquebox, which requires EAP (JBoss).

Anyway I'll look forward to hearing more about our options here going
forward... 

--Hugh

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey



More information about the aeolus-devel mailing list