The purpose of this page is to give recommendations for network/application architecture and configuration to be used in a production environment. Tomcat is designed and implemented as a servlet container, that is, its primary job is to process JSPs and servlets to serve dynamic content. Apache httpd web server was built to manage sessions and server static content.

A production configuration of Apache httpd and Tomcat would look like:

As an example of the above architecture, the following is our benchmarking environment (not development). The recommendations and guidelines are based on the results discovered during benchmarking.

	Database Server
	Dual P3 800Mhz, 2GB RAM
	Windows 2000 Server SP4
	MS-SQL Server 2000
	
	HTTP/Servlet Container Server
	P4 1.7Ghz, 1GB RAM
	Windows 2000 Professional SP4
	JVM Sun 1.4.1 JDK
	Apache 2.0.47 (with mod_jk2 2.0.43)
	Tomcat 4.1.27
	
	Web Stress Test Server
	P4 1.7Ghz, 512MB RAM
	Window 2000 Professional SP4
	OpenSTA 1.4.2.34

These guidelines apply to setting up a production environment using Apache and Tomcat. If you are using a commercial application server (WebSphere), these guidelines may not apply. However, the information may still be useful.

1. JVM Memory

Increasing the memory for the Java Virtual Machine can improve performance. The memory setting for Tomcat's JVM may be increased by editing the catalina.bat file located in the <TOMCAT_HOME>/bin directory.

Edit the CATALINA_OPTS:

     set CATALINA_OPTS=-Xms512m -Xmx512m

     -Xms minimum memory required to start tomcat and the web applications.
     -Xmx maximum memory the JVM will grow to.

It is very important not to increase the size of the JVM memory such that it can grow larger than the available amount of physical memory. This is to limit the OS from using slow virtual memory.

It should also be noted that on single processor architectures there is a performance pay off between high memory settings and garbage collection. For example, if the JVM memory is set high, then garbage collection will happen less frequently, however it will take longer to run as there is more memory to check. Conversely, if the JVM memory is set lower, garbage collection will run more frequently but take less time.

It was observed during benchmarking that when the garbage collector ran, response time increased by as much as 10 to 50 times the norm (depending on the user load).

On multiprocessor architectures with Java 1.4.1, a concurrent garbage collector can be used. This will set the garbage collector to run concurrently with Tomcat. Using this type of garbage collector will prevent the poor performance of the "stop-the-world" default garbage collector. However, there will be small increase in over all page access.

2. Debug Mode

Debug mode should be turned off. Debug can be turned off by commenting out the Trace bundle xml element in the s3.xml file. You may optionally set the <key>debug</key> to <key>error</key> which is the default (and would be used if the Trace.xml bundle were commented out).

By default, debugging is turned off for Tomcat and Apache. If you have explicitly turned them on, please make sure that debugging is set to a low verbosity.

3. Rows Returned

The number of results requested from the database should be kept low. The recommendation is 100. Adjustments can by made by editing the MAX ROWS SELECTED field in the System Options page of System Administration.

This only affects pages that have the Prev/Next buttons on them. The higher the max rows selected is, the more memory will be consumed on queries that return numbers of multiple rows.

4. Execution Threads

If the number of execution threads is too low then the CPU will never be entirely consumed, leaving precious resources unused. If the number of execution threads is set too high, the CPU can become pegged at 100% to quickly, leading to excessive contention.

Like all performance tuning, determining the number of execution threads is a bit of an art form. Many factors are involved, such as CPU power/architecture, available memory and application CPU usage.

It was discovered that the optimum execute thread setting was lower than Tomcats default settings (75 threads). Benchmarking using the CMA application showed that the optimal number of threads was 10.

The execution threads can be set by changing the minProcessors and maxProcessors in Tomcat by modifying the <TOMCAT_HOME>/conf/server.xml file. It is advisable to set the minProcessors equal to the max to avoid the overhead of runtime object instantiation.

5. Optimized JSP Settings

The following settings pertain to hot swapping and dependency checking for every page/resource served. Each time a resource is requested, Tomcat checks the date in the webapps deployment directory against the date of the file in the work directory. If the webapps file is more recent, some action takes place (update of the work file, recompile, etc…).

In a development environment, it is quite useful to have Tomcat check each time. However, it is expensive in a production environment.

Development - set to false. Turning development mode off will cause Tomcat NOT to check for JSP modification on every access.

Reloading - set to false. JSP should not be modified during deployment, therefore reloading is unnecessary.

Add or edit the following parameters in the <TOMCAT_HOME>/conf/web.xml file for the jsp servlet:

Note that these settings will require you to stop the Tomcat server, install the new .war applications, and remove the files in the work directory.

See the web.xml file.

6. Configure an External Web Sever

Tomcat is designed and implemented as a servlet container, that is, its primary job is to process JSPs and servlets to serve dynamic content. Tomcat contains a simple web server that is intended for development environments. The web server contained in Tomcat was not built to handle session management efficiently. However, the Apache httpd web server was built to manage sessions and server static content.

Our web applications contain dynamic and static (eg graphics, javascripts, style sheets, html) content.

It is recommended that an external web sever (Apache httpd) is used to serve static content and let Tomcat concentrate on the dynamic content.

Tomcat facilities external web servers via the JK2 connector component. The web sever will use a JK2 module to direct JSP and servlet requests to Tomcat and process other requests internally.

The configuration example attached is for use with the Apache web server.

The following steps are to configure Tomcat with Apache:

1. Configure the JK2 module to declare an AJP connector socket to tomcat (using the <APACHE_HOME>/conf/workers3.properties file):

	# Socket channel to bench mark application server port 8019
	[channel.socket:sphere:8019]
	
	Add the JSP and Servlet URI mappings
	
	# Uri mapping
	[uri:/s3check/*.jsp]
	[uri:/s3check/*.s3]

2. Configure Apache with the JK connector module and to serve the static content (using the <APACHE_HOME>/conf/httpd.conf file).

	# Load mod_jk module
	LoadModule jk2_module modules/mod_jk2-2.0.43.dll
	
	# Static files in the s3check webapp are served by apache
	Alias /s3check D:/dev/tools/tomcat/v4_1_27/webapps/s3check

3. Configure Tomcat to listen for AJP connections (using the <TOMCAT_HOME>/conf/server.xml file).