Re: Native tomcat vs external server

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 value right.

* 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.