Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Java: JRuby on Alpha is slow; any hope for improvement?

 
SOLVED
Go to solution
Highlighted
Regular Advisor

Java: JRuby on Alpha is slow; any hope for improvement?

For some time we have worked on a port of Ruby 1.8.2[1] for OpenVMS, to
the point where it is possible to successfully deploy cross-platform
applications using Ruby on Rails. However, it is cumbersome to keep up
the port on our own. There remains more work than we've been able to
keep up with in order to allow it to be merged upstream, we're lagging
far behind latest release of the language[2], are missing out on a
number of important features, and have some fairly serious performance
issues with Rails.

Seeking a solution to these problems, we spent the afternoon yesterday
installing and testing JRuby[3] on a small test OpenVMS/Alpha V8.3
system (a DS10/600 with 512M RAM and a RAID mirrored pair of 18G 15krpm
discs on Ultra-3 SCSI) with patches up to Feb. 2008. In theory, it runs
on all platforms that Java runs on, including OpenVMS, and will allow us
to keep up with latest releases of Ruby software without having to
maintain the port of the language ourselves. We were pleased to
discover that it does, in fact, run. However, our test results after
tuning system and process quotas as per doc[4] show Jruby on the fast VM
to be anywhere from 70% slower to 6 times slower than our C ruby port.

Is there hope that we might be able to tune further to the point where it
is practical to run applications on this platform? We had hoped JRuby's
performance on OpenVMS would be equal to or better than our C ruby port.

[1] http://vmsruby.rubyforge.org/

[2] http://www.ruby-lang.org/en/news/2007/03/12/ruby-1-8-6-released/

[3] JRuby is a cross-platform implementation of Ruby written in Java. See http://jruby.codehaus.org/

[4] http://h18012.www1.hp.com/java/documentation/1.4.2/ovms/docs/user_guide.html#processquotas
19 REPLIES 19
Highlighted
Honored Contributor

Re: Java: JRuby on Alpha is slow; any hope for improvement?

Have you read this article in the OpenVMS Technical Journal ?

Java and OpenVMS: Myths and realities

http://h71000.www7.hp.com/openvms/journal/v10/javavms.html

May be you could improve a few things with it ?
Highlighted
Honored Contributor

Re: Java: JRuby on Alpha is slow; any hope for improvement?

There's potentially no good answer available on native OpenVMS, unfortunately.

Java is slow most everywhere I've worked with it. (So too was a Java predecessor UCSD pCode, but then I'd be dating myself to even mention that.) The general discussion then becomes "how slow", and then whether or not the available performance meets minimal requirements.

As for a few potentially cheap fixes, your AlphaServer DS10 box is potentially short on physical memory; I'd monitor that, as well as paging and related I/O activity when you're running your tests. Do check process quotas and working-sets, too, as Java Looms Large.

There is only one (other) organization around that I'm aware of that has been looking at Ruby on OpenVMS, and this port is (further) behind current. Here's their port:

http://mvb.saic.com/freeware/freewarev70/ruby/

There are suggestions around platform vendors that are targeting Ruby and Rails, but most of the gear I'm dealing with toward that end is not HP gear. There are StorageWorks disks around, but...

gSOAP, ODBC or JDBC, or another approach toward data and application encapsulation might be an option here; remote access and linking over into the OpenVMS environment from your (I assume) web platform. Or slightly perversely, running OpenVMS inside an emulation, and running Ruby on Rails in the host environment.

There exists far more free source than the requisite free time and free help inevitably required to keep it upright and running and current.

Within HP, one of the folks to talk to in this general area has traditionally been John Apps, if you wish to send the discussion in the direction of HP.

If there is commercial and more formal interest in ports of these or other open source packages, there are folks here that might be convinced to port Ruby, Fortress or other recent languages or tools (gs/gv, Xpdf, etc) over to OpenVMS; to supplement the languages and the environments that are available from HP.

Stephen Hoffman
HoffmanLabs LLC
Highlighted
Honored Contributor

Re: Java: JRuby on Alpha is slow; any hope for improvement?

> As for a few potentially cheap fixes, your
> AlphaServer DS10 box is potentially short
> on physical memory; [...]

I'll say. 512MB? Yikes. Your workload may
(must) be different, but my junk XP1000
systems both have the max of 2GB, and could
use more.
Highlighted
Regular Advisor

Re: Java: JRuby on Alpha is slow; any hope for improvement?

labadie,

Interesting. Some of those suggestions may give us even better results with the C ruby implementation.

Hoff,

We did look at main memory during testing. In MON CLUS on an otherwise idle system while running the tests, memory usage peaked at 55%, so I don't think that's our biggest constraint. The working set and page file quotas are at recommended values now.

The page you linked to contains an earlier version of the same port we inherited from Masamichi Akiyoshi.

As for the other suggestions, here's a bit of background. The Ruby application code development we are doing runs in parallel with a porting effort from VMS -> Windows. To be honest, as much as I love VMS, I'm constantly frustrated in my development efforts by the lack of tools that I have come to expect as standard on other platforms, e.g. Linux. So I want to do as little as possible that keeps us tied to VMS. Points against solutions that have us redesigning our applications for the sake of VMS. Points for solutions that allow us to continue developing apps to be deployed on either platform without modification. That was the big appeal of JRuby.

It was a strange set of circumstances that led to us "owning" the Ruby port to begin with. So long as Masamichi (who worked for HP in Japan) was working on the port, we figured it had a future. When he stopped development, we picked it up because we were already deploying software with it and therefore needed it to go on. While I'd love it if HP picked this up, I have to be realistic about it. So far, we haven't had people flocking to our port to help out, so I doubt if there is sufficient demand to make it commercially viable.

Steven,

Yeah, this is only a test system representing the low end of what we're likely to encounter in the field. Even so, from what I observed above, it doesn't look like that's a limiting factor ... yet. And if it is, it wouldn't be hard for us to add more RAM to see if it helps. But I'm not rushing to do that until I'm sure we have a real problem.
Highlighted
Honored Contributor

Re: Java: JRuby on Alpha is slow; any hope for improvement?

The memory requirements for a somewhat reasonable Java performance are 1Gb memory, and a processor running on 500Mhz. AT LEAST. Furthermore you should tune your VMS box to behave as a Unix one.
Of course it depends on the size of the application, the number, size and lifespan of objects. Smaller applications run pretty usable on smaller systems, bigger ones may require considerable more.

Add Ruby's requirements and 512 Mb will surely be way too small, causing massive paging (you'll hear your drive grind on each garbage collector activity). (Much) more mamory will surely help. Adding processor power will add performance gains as well.

On tools: have you checked out Distributed netnbeans: Netbeans on Windows or Linux, and a (java based) server on VMS. Usable for Java (duh), C, C++, FORTRAN, COBOL, Pascal, DCL at least. It DOES run on 512 Mb, but the more memory and processor power, the luckier teh server runs.
Willem Grooters
OpenVMS Developer & System Manager
Highlighted
Regular Advisor

Re: Java: JRuby on Alpha is slow; any hope for improvement?

I appreciate that the limited memory on the test system is insufficient for running apps of anything more than trivial complexity. My test script, however, was rather small and simple and as I said, I never observed total system memory usage above 55% in my tests, so that would seem to indicate we would not see enormous gains in performance with a memory upgrade for these tests. I can well imagine I'd see even worse performance if I tried to run, say, Rails itself. But without an assurance that I'm on the path to achieving acceptable results, I'm disinclined to spend the time it would take to go further.

The purpose of the exercise was not to evaluate the performance of the test system, but to run some simple trials to see if throwing more resources (time and/or hardware) at the project would be worthwhile. We believe they were fair trials. While my results from those trials indicate it is not worth investigating further, we will keep an eye on JRuby as the developers are actively working on performance issues and may turn out a release in future that is worth considering.

I also posted this afternoon to comp.lang.ruby, linking back to this discussion, in case the developers are following and have anything else for us to try.
Highlighted
Advisor
Solution

Re: Java: JRuby on Alpha is slow; any hope for improvement?

I have also tested Jruby on OpenVMS and it works (both executing a ruby script with the Jruby interpreter and executing bytecode compiled from a ruby script). And yes, it does not perform well. Why? because the OpenVMS filesystem is very slow and the jvm has to handle a lot of jar archives. If you want to greatly improve the Jruby performance, put Jruby in a DECram and build a shadow set with this DECram and a LD device for the persistence.

I have played with the ruby port from the HP japanese guy several years ago and found many limitations. For example, the interpreter uses environment variables to have access to some libraries and of course OpenVMS does not like it. Most of these limitations disappear with Jruby.
Highlighted
Honored Contributor

Re: Java: JRuby on Alpha is slow; any hope for improvement?

> We did look at main memory during testing.
> [...] memory usage peaked at 55%, so I
> don't think that's our biggest constraint.

Did you look at the page fault rate, too?

> The working set and page file quotas are
> at recommended values now.

Recommended by ...? It may be easy to keep
memory free, if you don't let anyone use it.

More analysis may be useful. (No bets, of
course.)

SET RMS_DEFAULT might have some effect, too.
Highlighted
Regular Advisor

Re: Java: JRuby on Alpha is slow; any hope for improvement?

I don't know what a reasonable page fault rate is for this app, so I don't know what to look for to know if I need to tune it further.

As for recommended values, as I said in my original post, the doc I am using is in footnote 4.