|
Pete Hall skrev:I'm using the classic JVM 1.6
Yes, it's the initial request that causes the biggest hit (by far.) I'mFirst of all, which JVM do you use? The Classic or the Technology one?
more concerned about the impact of multiple requests in production.
Based on advice I've gotten on this list, I have concluded the following:Ok. I will experiment with that.
* The Classic JVM takes ages to pull up and you need to help it all you
can by preserving jar and class files unmodified in the IFS. (The
exploded wars e.g.).
* The default behaviour of OS/400 is to aggressively swap out memory
used by JVM's (as they are large), which doesn't work well with the Java
Garbage Collector which want's the whole heap in memory. It appears the
typical advice is a separate storage pool.
* The default garbage collection values for the Classic JVM are tooHmmm. I didn't realize I could control that. More reading...
small for non-trivial Java programs, and they do not automatically
adjust. It requires experiments in the scenario it is to run to get the
value right.
* Given enough space to avoid swapping, and given enough time to settleThat's ok. I can script the startup so that it loads the java classes
after startup, I've found the Classic JVM to have acceptable performance
comparable to a PC, but it really takes time to get there.
If you run under the Classic JVM, I would suggest you enable garbageOk. Good tip. Thanks
connection logging to QPRINT (-verbosegc or OPTION(*VERBOSEGC) I belive)
so you can get an idea of what goes on. The BIRT reports probably takes
a LOT of memory so a lot of aggresive garbage collections probably happens.
I don't understand. Are you saying that I need to do something otherTomcat 6 extracts the contents of the war file already. I removed theNo. It is the unpacked version that Tomcat uses.
war files from the webapps directory. That didn't seem to make a
difference.
By the way, we found that the QSH command "du" includes the hidden dataAlso good advice. Thanks Thorbjoern.
produced by the JVM. You can use that to get an idea of the amount of
work done by comparing to the size of your own files.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.