Pete Hall skrev:
Yes, it's the initial request that causes the biggest hit (by far.) I'm
more concerned about the impact of multiple requests in production.
First of all, which JVM do you use? The Classic or the Technology one?
Based on advice I've gotten on this list, I have concluded the following:
* 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 too
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
* Given enough space to avoid swapping, and given enough time to settle
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 garbage
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.
Tomcat 6 extracts the contents of the war file already. I removed the
war files from the webapps directory. That didn't seem to make a difference.
No. It is the unpacked version that Tomcat uses.
By the way, we found that the QSH command "du" includes the hidden data
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.