Tomcat Resource Pools
First, a review of the types and roles of Tomcat component pools is in order. A resource pool is a pool of reusable objects that are vital for application processing yet expensive to instantiate on demand. Tomcat's connector thread pool and database connection pool are two such pools. They have a direct impact on the overall throughput of the server as well as on the individual applications.
Connector Thread Pool
The connector pool is a pool of threads that accepts connections from standard Tomcat connector ports (e.g., 8080 for HTTP, 8009 for AJP) and hands them off to the processing components. This pool plays an essential role in Tomcat's processing throughput capacity. Every single request directed into Tomcat goes through the connector pool.
If the pool is too small and too many requests get backlogged, the request gets denied.
If this pool has too few active request-processing objects and the traffic increases dramatically, a delay in request processing results due to pool component instantiation. If the pool is too large (i.e., the number of ready threads is too high), CPU cycles and memory may become overused.
Therefore, knowing how to set the proper size and other parameters of this pool is crucial for the Web application to function properly under heavy loads. By default, the connector pool is preconfigured with the following settings:
- Minimum number of spare threads (Number of threads that are always in the pool) 4
- Maximum number of threads in the pool 200
Database Connection Pool
The database connection pool is an essential component to all J2EE applications that utilize pooled JDBC connections, which in my experience is the majority of J2EE applications. The database connection pool, as provided by Tomcat's implementation of Jakarta's DBCP, follows a similar configuration pattern as the connector pool.
By default, the database pool always holds three idle connections and a maximum of 15 active connections. If the connections are exhausted, the application will not be able to get a connection to the database, causing run time errors that are potentially fatal for the application.
Resource Pools Under Heavy Loads
Both of these pools, under heavy loads, can quickly become major performance bottlenecksa hard limiting factor in application scalability. At the same time, with the proper knowledge of real-time resource utilization, you can achieve amazing results in application responsiveness and scalability.
The challenge is performing appropriate data collection and monitoring of pooled resources under heavy loads in real time and with low overhead. The solution is a low-overhead, near-real-time monitoring and data collection component, which gives you the best picture of Tomcat's pooled resources utilization. With that information, you can configure Tomcat's pools to handle any projected demands with relative ease.
Before diving into the proposed solution, get to know the Tomcat components that will play key roles in the custom performance-monitoring component.