Tomcat Performance JVM Arguments

I have a Tomcat 4.1.24 running as a stand-alone HTTPS server. It
contains one servlet with no static content. This single servlet
tunnels RMI calls from clients to an EJB server inside the firewall.
(For those of you interested check out JProxy at
http://www.jproxy.com). The connection between the clients and Tomcat
are encrypted with SSL.

I noticed by default that Tomcat is started with no performance
related JVM args. Does anyone have suggestions for JVM args? The
following substantially increased performance:

-server -XX:+DisableExplicitGC -Xms2048m -Xmx2048m

Are they any additional parameters that work well for Tomcat?

I'm testing performance using 150 client simulators. With all 150
simulators running my CPU usage is about 30%.

Any advice would be greatly appreciated!

-- John

John Davison wrote:
> I have a Tomcat 4.1.24 running as a stand-alone HTTPS server. It
> contains one servlet with no static content. This single servlet
> tunnels RMI calls from clients to an EJB server inside the firewall.
> (For those of you interested check out JProxy at
> http://www.jproxy.com). The connection between the clients and Tomcat
> are encrypted with SSL.
>
> I noticed by default that Tomcat is started with no performance
> related JVM args. Does anyone have suggestions for JVM args? The
> following substantially increased performance:
>
> -server -XX:+DisableExplicitGC -Xms2048m -Xmx2048m
>
> Are they any additional parameters that work well for Tomcat?
>
> I'm testing performance using 150 client simulators. With all 150
> simulators running my CPU usage is about 30%.
>
> Any advice would be greatly appreciated!

Profile your application before you try to determine how to improve
performance. It is quite possible, for instance, that the bottleneck is
in the network stack and not in the JVM. (In fact, if CPU usage is not
maxed out then likely the problem _isn't_ local to the VM.) A bottleneck
in the VM also need not be directly related to GC, which is what the
options you suggested seem to be aimed at. Just throwing options at the
VM that sometimes improve performance is a terribly poor method of
optimization.


John Bollinger
jobollin@indiana.edu