Alpaha ES45 OS 8.3: JAVA 1.5-7 is performance slow compared Windows OS 2000 OS is twice faster.

[prakashsmtr]

We have Alpha server ES45 4 CPU, 1.25 Ghz each(total 5Gz if works in parallel,  Open VMS 8.3,JAVA 1.5-7

 But still JAVA  's performance is half of  compared to Windows system  laptop and it is only  a 1400Mhz CPU with 2Gb of RAM running Windows 2000 run twice faster than VMS system.

Sample process ran on VMS took 10 Mins, but same process Windows took only 4 Mins.

The problem was narrowed down to Garbage collection: when GC in progress all Java process stops this in turn increase CPU time utilization. and total elapsed time.

Could anybody please tell the ways to improve Java performance on VMS, specially for Garbage collection.

Regards

Prakash

[Duncan Morris]

Prakash,

have you followed the guidelines here....

http://h71000.www7.hp.com/ebusiness/optimizingsdkguide.pdf  ?

Duncan

[prakashsmtr]

Yes, we have followded

http://h71000.www7.hp.com/ebusiness/optimizingsdkguide.pdf  still, found the same problem.

Regards

Prakash

[Hoff]

Processor gigahertz is not a portable measure of system performance.

You're seeking to compare a 1.4 gigahertz box of one architecture with a 1.25 gigahertz processor of a completely different architecture, and that doesn't work.  Even comparing gigahertz values within an architecture can be dicy; from one processor generation to the next, or across processor families within the architecture.

Whether with embarrasingly parallel applications (of which Java is not) or with single-stream performance, you're only permitted to cite the aggregate GHz values for multiprocessor servers if you're working in a marketing organization.  

First, see if Alpha is just slower, as a starting point.  Run your Java tests on Java 6 and recent OpenVMS I64 server with patches and such loaded.  See if that's closer to the performance you're expecting.

As for other options (and given you're still on an AlphaServer ES45, I might infer that upgrades are unlikely) there's an old tuning guide Optimizing Java™ Technology Software Performance on HP OpenVMS available that might be worth reading.  (That's the newest available, but it's most of a decade old.)

Ignoring the obvious stuff (see above), what you're seeing is fairly typical of Java performance in general.  If you want the best performance with Java, then Sun Solaris on x86-64 and SPARC, and Microsoft Windows on x86-64, are generally your best choices; those platforms receive the bulk of the performance-related work that goes into Java, after all.  And garbage collection has been a long-standing issue with Java application performance; newer Java releases are better hear.

[prakashsmtr]

Could anybody please answere this question..as still we face java performance slow ....

"why the JAVA application stalls when the GC is running"..? Is this a normal/expected behaviour of Java on Alpha VMS paltform...?

Regards

Prakash

[Hoff]

Relative low-performing Java code is commonplace on OpenVMS.  It's expected.

If you seek better performance with your Java code, then try running it on a (much) newer (Integrity) system with OpenVMS, or migrate your Java to a system that sees more performance-related and tuning work.  Windows 2000, for instance, clearly has better performance, and I'd tend to expect yet better performance out of Windows 7.

If you want an official answer (or if you want somebody to look at your code and see if there are problems with it), then the HPSC forums aren't the path to that answer; check directly with HP support, or with somebody that more directly supports and tunes Java code.

[Dennis Handly]

>"why the JAVA application stalls when the GC is running"? Is this a normal/expected behaviour of Java on Alpha VMS platform?

I'm not sure about that version of Java but typically GC needs all the threads stopped in order to accurately scan all of memory.  There are versions that can do this in parallel.

Some blog articles about java heap performance:

http://h30499.www3.hp.com/t5/Business-Service-Management/Plugging-the-leaks-best-practices-for-troubleshooting-Java/ba-p/5410751

http://h30499.www3.hp.com/t5/Business-Service-Management/Plugging-the-leaks-Blog-2-Traditional-approaches-to/ba-p/5410763

http://h30499.www3.hp.com/t5/Business-Service-Management/Plugging-the-leaks-Blog-3-A-novel-approach/ba-p/5410775