Tomcat - Maxthreads VS Maxconnections

Tomcat - maxThreads vs. maxConnections

Tomcat can work in 2 modes:

• BIO – blocking I/O (one thread per connection)
• NIO – non-blocking I/O (many more connections than threads)

Tomcat 7 is BIO by default, although consensus seems to be "don't use BIO because NIO is better in every way". (And BIO has been completely thrown out of 8.5.0 and later versions.) You set this using the protocol parameter in the server.xml file.

• BIO will be HTTP/1.1 or org.apache.coyote.http11.Http11Protocol
• NIO will be org.apache.coyote.http11.Http11NioProtocol

If you're using BIO then I believe they should be more or less the same.

If you're using NIO then actually "maxConnections=1000" and "maxThreads=10" might even be reasonable. The defaults are maxConnections=10,000 and maxThreads=200. With NIO, each thread can serve any number of connections, switching back and forth but retaining the connection so you don't need to do all the usual handshaking which is especially time-consuming with HTTPS but even an issue with HTTP. You can adjust the "keepAlive" parameter to keep connections around for longer and this should speed everything up.

What are acceptCount, maxConnections and maxThreads in Tomcat HTTP connector configuration?

• acceptCount -- The maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default value is 100.

• redirectPort -- if this Connector is supporting non-SSL requests, and a request is received for which a matching <security-constraint> requires SSL transport, Catalina will automatically redirect the request to the port number specified here.

• maxConnections -- The maximum number of connections that the server will accept and process at any given time. When this number has been reached, the server will accept, but not process, one further connection.

• connectionTimeout -- The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented

acceptCount is like the line waiting to get into a popular nightclub that is full. (maxConnections) when some people leave maxConnections goes down allowing more people to connect from the acceptCount waiting list. The connection timeout is simply how long it will wait for the request. So you can either make the line longer (acceptCount) or make the nightclub larger (maxConnections)

Redirect port is how/where it handles a redirect due to a security restraint.

Tomcat 8 NIO,how it works?

The maximum number of client connections is acceptCount + maxConnections. Too low and requests may be rejected unnecessarily. Too high and clients may be starved if throughput can't keep up.

acceptCount: - 100 by default - This is used as the backlog parameter for ServerSocket.bind. The OS's TCP stack will queue at most acceptCount pending socket connections. This occurs before Tomcat starts processing the connection.

maxConnections: - 10,000 by default - The maximum number of connections that Tomcat allows to be in progress internally.

maxThreads: - 200 by default under NIO and NIO2 - Maximum number of concurrent request processing threads.

The goal is to optimize service availability and performance and utilize resources efficiently. The settings will depend on the latency and load distribution of your request processors.

There are many different approaches to capacity planning depending on the goals. A simple option is to increase maxThreads to the point where the server wouldn't be able to safely process any additional requests within a reasonable period of time. At this point of saturation, accepting more connections would be inadvisable since it would take too long to clear them out. So consider how much CPU time and RAM each processing thread requires and how many can safely run at the same time.

server.tomcat.max-threads VS corePoolSize VS spring.datasource.tomcat.max

Assuming you are using Spring Boot 2.1 and haven't changed the defaults (using Tomcat as the embedded container and Hikari as the connection pool).

Tomcat Request Handling Threads

To modify the number of threads (tomcat by default already uses 200 so why would you need to change it!) use the properties in the server.tomcat namespace (those are specific for Tomcat!. So use server.tomcat.max-threads to control the number of request handling.

To limit the number of concurrent HTTP connections use the server.tomcat.max-connections (default value 10000). This is basically the processing queue which the request handling threads use to pick/steal work from.

Number of Threads for task execution

For controlling the number of threads used by the default created TaskExecutor in Spring Boot 2.1 use the properties in the spring.task.execution namespace. So use spring.task.execution.pool.max-threads to set the maximum number of threads to use for @Async. The spring.task.execution.pool.core-size controls the core (minimum) pool-size. Increasing the max-threads property without limiting the queue size through spring.task.execution.pool.queue-capacity has no effect. The default queue size is unbounded and everything will not result in growing the number of threads beyond the core-size.

Connection Pool properties

Finally to specify the connections for your connection pool (the default for Hikari is 10!). Use the spring.datasource namespace properties and specifically the one for your connection pool (default is Hikari so the ones in spring.datasource.hikari, the spring.datasource.tomcat are for the Tomcat JDBC connection pool used as default on Spring Boot before 2.0). So set the spring.datasource.hikari.maximum-pool-size to manage to max number of threads.

Note

They don't have anything to do with each other and should be confused with each other as well (imho this is already clear in the reference guide that each serves a different purpose). See Appendix A of the Spring Boot Reference Guide for a list of common properties.

---

Related Topics