Tomcat Performance Tuning: Core Components and Key Parameters

For many SpringBoot applications the default servlet container is Tomcat. When traffic grows, simply scaling out may not be enough, so tuning Tomcat can improve performance without extra cost.

Component Architecture

Tomcat is organized into several components: Server, Service, Connector, and Container, each with a specific role.

Server : the top‑level abstraction representing the Tomcat instance; it can contain one or more Services.

Service : groups a set of Connectors and a single Container; multiple Connectors allow handling different protocols.

Connector : manages client connections and supports protocols such as BIO, NIO, and AIO, shielding the Container from protocol complexity.

Container : processes business logic; the Connector forwards requests to the Engine inside the Container.

Inside the Container there are further sub‑components such as Engine, Host, Context, and Wrapper, which map to virtual hosts, web applications, and individual Servlets.

Core Parameters

Understanding Tomcat's request handling flow—client → Connector → Engine → Connector → client—highlights three key parameters that affect performance.

acceptCount : the maximum number of connections the operating system will accept when the thread pool is full and the Connector queue is at its limit.

maxConnections : the maximum number of connections the Connector queue can hold when all Container threads are busy.

maxThreads : the maximum number of request‑processing threads in the Container thread pool.

maxThreads

Tomcat 7/8 default this value to 200. A practical way to calculate an appropriate size is:

((IO time + CPU time) / CPU time) * CPU cores

This formula aims to keep CPUs busy while waiting for I/O. Because I/O time usually dominates, the computed maxThreads is often much larger than the number of CPU cores. However, setting it too high can cause excessive context switching, so the calculated value should be used as a baseline and then refined through load testing.

maxConnections

This defines how many connections the Connector can queue when all threads are occupied. A common rule of thumb is to set it equal to maxThreads, ensuring that queued connections wait only for a short time before being processed.

Lowering maxConnections can reduce response latency but may also limit throughput if set too low.

acceptCount

When both the thread pool and the Connector queue are full, acceptCount limits how many additional connections the operating system will accept before rejecting new requests (default 100). It should not exceed maxConnections, otherwise many connections would remain unprocessed.

Historically, acceptCount matched maxConnections in BIO mode; with NIO/AIO the OS can accept more connections, allowing the Connector to pull them from the OS queue without extra TCP handshake latency.

Other Useful Parameters

connectionTimeout : timeout for establishing a connection.

minSpareThreads : minimum number of idle threads kept alive to handle sudden traffic spikes.

Summary

The article covered Tomcat's core components, the request‑processing flow, and the three essential tuning parameters—maxThreads, maxConnections, and acceptCount—along with practical advice on setting them and additional knobs such as connectionTimeout and minSpareThreads.

For maxThreads, use the I/O‑CPU formula as a starting point and validate with stress testing. For maxConnections and acceptCount, align them with maxThreads and adjust based on desired latency and throughput.

By applying these settings, you can improve Tomcat performance without adding new hardware.