One of the great things about the Tomcat application server is the fact that the software used to develop and test applications is the exact same software that gets installed and used in a full scale production environment. The packages and binaries a software developer downloads and installs on a local Ubuntu image are the same binaries and packages that get installed by the system administrator on the Linux box running in production. Unfortunately, this can also cause some problems, as the binaries downloaded from apache.org are not necessarily configured to effectively leverage the enhanced performance capabilities of server-side hardware. If a Tomcat installation is performed on a server using the default settings, simple optimizations get missed, and the production hardware will not perform at its optimal capacity.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The most commonly misconfigured settings on a production Tomcat server can be found in the attributes of the connector.
Common misconfigurations on Tomcat
The most commonly misconfigured settings on a production Tomcat server can be found in the attributes of the connector element, which is defined in the Tomcat server's server.xml file. By default, the maxThreads attribute is set to a humble 200. This is fine for a single core machine, but can be multiplied linearly given the number of processors on the production machine. On a machine with four processors, setting this value to anything between 800 and 1000 will not cause a problem. And if the configured number ends up far exceeding the number of threads required, the thread pool will naturally scale back this number when the server load is low.
The other most often misconfigured, or for that matter, outright missing setting on a production Tomcat server has to do with compression. Any communication between the client and server that is primarily text, be it HTML, XML or simply Unicode can regularly be compressed up to 90% using a simple and standard GZIP algorithm. This can have a massive impact on reducing network traffic, allowing responses to be sent back to the client much faster, while at the same time allowing for more network bandwidth to be available for other network heavy applications.
Configuring the Tomcat server
A sample connector entry in Tomcat's server.xml file that takes advantage of these two settings would look like this:
There is no doubt that the ability to use the same Tomcat binaries both on the production machine and on a developer's local desktop makes the Apache Tomcat software incredibly user friendly, but at the same time, system administrators must pay attention to the way Tomcat installations are configured on the server. By ensuring that the thread pool is properly configured based on the number of processors in the system, and that highly compressible content types are being delivered to the client in a zipped format, system administrators are ensuring that their servers are configured to deliver an optimized experience to the end user.
Do you have any good tips that will help administrators save time when configuring and optimizing the Tomcat application server? Let us know about your favorite tips and tricks.
Tomcat: The Definitive Guide by Jason Brittain
Apache Tomcat 7 Essentials by Tanuj Khare
Java Performance by Charlie Hunt
Java Performance Tuning (2nd Edition) by Jack Shiraz
Java Performance and Scalability by Henry H. Liu