Apache Tomcat Configuration Tips and Tricks
Apache Tomcat configuration can be a challenge, and one that enterprises often fall short on. In this blog, we discuss five of our favorite best practices for configuring Apache Tomcat, and other considerations for teams deploying Tomcat for mission-critical applications.
- Before You Begin
- 5 Tomcat Configuration Best Practices
- Other Considerations for Configuring Tomcat
- Final Thoughts
Before You Begin Your Tomcat Configuration
For many open source products, the way you configure your tool greatly and totally impacts how your software runs and operates. There are some that use out of the box configurations to get up and running, then there are those that make sure every detail is in place before they ever start up their software. Knowing what to look for in a configuration is important, especially when you or your organization is paying for every resource used on a cloud-based service like AWS or Azure.
Having a thorough understanding of the default configuration is the most logical place to begin with Tomcat, or any product for that matter. Today we’ll be talking about Apache Tomcat and what you can do to enhance your experience with the product. By default, out of the box Tomcat is very insecure and is only designed to get you up on your feet and running in the most basic of ways.
Before we move on to our best practices, let's look at the configuration files and basic terms you'll need to work with to configure Tomcat.
The server.xml file is the main configuration file used for Tomcat. Combined with web.xml, these two files basically run the show when it comes to Tomcat configuration. Both are in the conf directory of the Tomcat root folder. The server.xml file can be broken down into several categories: top level elements, the connectors, containers, nested components and then the rest of the global settings. The server.xml file fully dictates how Tomcat is configured during start up and the settings it will use.
Top level elements contain the server, service and connectors elements. Connectors allow Catalina to forward requests from specified ports to a single engine component for processing. You’re able to define both AJP and HTTP connectors in server.xml. Containers are used by Catalina to direct requests to the correct processor. When it comes to the nested components, these are used by the container element and defines additional functions.
Connector component that uses AJP protocol to communicate with a web connector.
Element used to provide session replication, WAR deployment, and context attribute replication.
Element used by Catalina for directing requests to the right processing destination.
Represents a single web application, includes path information for directing requests.
Nested within a service element, is used together with connectors, and processes all requests tied to its assigned parent service.
Global Naming Resources
Specifies global JNDI resources for a specific server.
Provides stand-alone web server functionality, serves as a HTTP/1.1 Connector.
Nestable element that performs an event-driven action.
Used by the container element to define additional functions.
Nestable element used to define a database with roles, usernames, and passwords for the assigned container.
Directs Catalina to static resources used by web applications.
Defines single Tomcat Server, includes Logger and ContextManager elements.
Nestable element for Server element that is used to contain Connector components assigned to a single Engine component.
Versatile nested component for Engine, Host, and Context elements. Used to insert functionalities into request processing pipeline.
Standardized by the Servlet specification, the web.xml file specifies information that is used to deploy and configure the various components of a web application. When configuring this file you are able to map components, such as JSP. You can also define values for all contexts inside the file. By using web.xml to define your contexts instead, Tomcat will use web.xml as a base config which later can be overwritten by other app-specific web.xml files.
5 Tomcat Configuration Best Practices
When it comes to writing up your configuration files, there are a few things to consider and to keep in mind. The following tips are just some general suggestions and starting points for your initial Tomcat configuration and are of course subject to change based on the nature of your webapp. But for the most part, these considerations apply in a broad sense to how webapps function today.
1. Use Only the Applications You Need
There are a handful of applications that Tomcat utilizes out of the box that can be modified or removed to improve performance.
The ROOT application displays a splash page that shows Tomcat is up and running. There are also some example files provided that can be removed if not needed. Host Manager is a feature used to manage virtual hosts in Tomcat. Depending on your needs you may or may not need this. If you do, please use the official Tomcat documentation to secure the settings properly, otherwise, it can be removed for security purposes.
The same can be said for the Manager application. While not accessible by default without any users being configured to use it, this application is used to remotely deploy web applications. At the same time, this feature can be manipulated by attackers allowing access to the host machine. This is primarily due to there being weak security configuration and credentials. If not needed, it’s advised you remove it. The documentation for Tomcat is also included but can be found online for easy reference. If not needed it can also be removed.
2. Configure Your Heap Memory Size
Anytime Tomcat has to invoke the garbage collector, precious resources are being used that could be used otherwise to run the app.
One thing you can do to prevent garbage collection from occurring as often is to increase the default heap memory maximum. Doing this will give the JVM more resources to continue to run the web application. By doing this, your server can respond to requests faster and perform more efficiently over time.
You can also be sure to start the JVM with the maximum memory available to it by setting the -Xms switch value to the same value as maximum memory. By doing this the JVM will not have to resize or reallocate heap memory while serving requests.
3. Tune Your Connector Thread Pool Settings
Getting the best performance out of your server depends on a lot of things, but one of the more important pieces to tune is the Connector thread pool settings. By adjusting the maxThreads setting, you are able to adjust the servers performance to match the request load from clients.
Of course, adjusting this setting is easier said than done and will likely take some experimentation and monitoring to find the “sweet spot” where you’re maximizing performance for the cost. If you set maxThreads too high, your Tomcat startup time can take exceptionally longer and cause server slowness during peak load times. If you set it too low could mean that you don’t have enough threads available to serve all incoming requests causing requests to sit idle until a resource becomes available. You also wouldn’t be utilizing your hardware fully if your setting is too low.
4. Adjust Your Database Connection Pool Elements
With regards to databases, there are some considerations to follow. Because many web apps use a relational database it is important to ensure the connection pool settings are set correctly. The three most important attributes of the Resource element are maxActive, maxIdle and maxWait. These three are used to define the database connection pool. You don’t want Tomcat waiting around for slow database queries.
5. Cache Your HTTP Headers
Caching HTTP headers is a simple yet effective way to cache the static content of your webapp and can greatly increase the user experience relative to performance. In order to do this though, you must have a thorough understanding of your webapp and how it functions traffic wise. It boils down to setting the right set of response headers and values for when Tomcat serves up static files.
Other Considerations for Configuring Tomcat
Ensuring that the operating system that Tomcat is running on is finely tuned is one last thing you should consider for optimizing your webapp server. Beginning with the sizing of the operating system, you want to be sure you have enough physical resources to run your webapp properly. Monitoring CPU and memory utilization is key to preventing bottlenecks from occurring.
When running Tomcat in a virtual machine you want to ensure that the virtual machine ready time is well below 5% so that the virtual machine has access to the CPU when it needs it. When using Amazon AWS or Azure you want to make sure that DTU usage is not close to 100%.
A well-thought out Tomcat configuration can make a big difference for performance and security, and those improvements can have a direct impact on your business. And, for teams hosting their applications in the cloud, the performance benefits can have a direct and positive impact on hosting overhead.
While the tips and tricks we covered here today are a good starting point for many webapps, they barely scratch the surface of what is possible. And, of course, any "best practice" should only be viewed as a best practice when it suits the needs of your application(s).
Need Help Configuring Your Tomcat?
OpenLogic provides expert technical support and services for teams working with Apache Tomcat. Whether you need help with configuring, optimizing, migrating, or maintaining your deployment, our team of experienced enterprise architects is ready to help. Visit our Tomcat support page today to learn more.
- Blog - Tomcat vs. TomEE: Comparing Specifications and Use Cases
- Blog - 5 Apache Tomcat Performance Best Practices
- Blog - What Is Apache Tomcat?
- Blog - GhostCat Vulnerability in Tomcat
- Blog - Apache Tomcat 7: EOL Dates and Considerations
- Blog - Apache Tomcat 8: Overview, Clustering, and More
- Blog - Apache Tomcat 10: Key Considerations for Deployment
- Blog - Apache Tomcat Clustering: The Ultimate Guide
- Blog - Apache Tomcat Security Best Practices