If you and/or your third party software use a log facility (I think most 
software do) such as log4j you can turn on debug mode and inspect the 
log’s timestamp and see where the time goes

Easier said than done, especially for big systems. Also, as a rule, requires
some instrumentation to be included in the application being tested.
Otherwise, only servlet/enterprise bean-level information would be available
- personally, I find that insufficient. In any case, I certainly did not
mean that type of 3rd party software.

Lo 
________________________________________________________

Misys Banking Systems
Key West / Windsor Road / Slough / SL1 2DW

T +44 (0)1753 708 053 
M +44 (0)7903 181 030 
raikovl1@xxxxxxxxx 

www.misys.com 
________________________________________________________________

This email and any attachments have been scanned for known viruses using
multiple scanners. We believe that this email and any attachments are virus
free, however the recipient must take full responsibility for virus
checking. This email message is intended for the named recipient only. It
may be privileged and/or confidential. If you are not the intended named
recipient of this email then you should not copy it or use it for any
purpose, nor disclose its contents to any other person. You should contact
Misys Banking Systems so that we can take appropriate action at no cost to
yourself. 
www.misys.com <http://www.misys.com/> 



-----Original Message-----
From: Bruce Jin [mailto:brucej@xxxxxxxxxxxxxxxxxxxx]
Sent: 17 October 2006 14:39
To: Java Programming on and around the iSeries / AS400
Subject: Re: Optimizing Native Java


If you and/or your third party software use a log facility (I think most 
software do) such as log4j you can turn on debug mode and inspect the 
log’s timestamp and see where the time goes

regards.

Raikov, Leonid wrote:
The most important thing is to understand where the time goes. Situations
when there are no bottlenecks and every class contributes to poor
performance in equal measure are pretty rare. What you need is to a)
understand what threads are primarily involved in productive work and then
b) draw a chart describing what each of these thereads is busy doing (e.g.
50% of the time spent waiting for JDBC queries and 50% of the time doing
XML
processing). You can hardly achieve this without Java performance analysis
tools for System i. IBM Job Watcher is what immediately springs to mind,
but
JW data is not easy to analyse, to say the least. There are other tools,
some of them pretty good, but none of them in the Open Source domain, as
far
as I know.  

As for the magic button, there is none, I'm afraid. I would be suprised if
memory alone could make you happy. That is, unless you're running your JVM
in a 50MB pool.  

Lo
-----Original Message-----
From: albartell
To: 'Java Programming on and around the iSeries / AS400'
Sent: 10/16/06 4:12 PM
Subject: Optimizing Native Java

Hi All,
 
I am just completing a project where I wrote a Java proxy of sorts and
there
were a bunch of third party jar files involved in the mix. To make a
long
story short we are not satisfied with the performance we are getting out
of
the Java processes on the iSeries (note the Java is running in it's own
job
listening to a data queue - only one JVM startup).  We have run the
CRTJVAPGM against all .class and .jar files involved and are wondering
are
there any other mechanisms to look at concerning getting more speed on
the
Java end?
 
Obviously one solution would be to throw more memory at it, but is there
a
way to section off the memory so this Java process gets sole use of it
(similar to how you can do the same for Websphere Application Server)?
 
Any other idea's?
 
Aaron Bartell
New Tool! - RPG Chart Engine - visit www.mowyourlawn.com
<http://www.mowyourlawn.com/>  for more info.
 
 
  


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.