Tomcat’s acceptCount, maxThreads, connectionTimeout parameter adjustment

  network, tomcat

AcceptCount value adjustment (Default 100)

The experience value of acceptCount ranges from 50 to 300. When tomcat’s processing power is not fast enough, you can adjust the value, which is more useful.

  • When the concurrency of the system is relatively large, close keep alive and adjust the value appropriately.

  • When the connection is established and the worker thread is often not available for processing, the value can be appropriately lowered to open keep alive

When this value is set to be relatively large, the sudden increase of requests will quickly fill the accept queue (the connection is completed in three-way handshake, waiting for the worker thread to process the response. If the service has not been received, the client will not receive the response, resulting in read timeout. The worst case is that the connection has waited for a long time in the accept queue, and it has timed out when the worker thread service is available. This actually wastes a lot of connections), which makes woker thread very busy. When it exceeds the system’s capacity, requests keep piling up, and then causes the worker thread cpu to starvation death. Therefore, it is necessary for the system to protect itself. When the load capacity is exceeded, it will fail fast quickly and return to 503.

Therefore, it is necessary to reasonably evaluate the size of the worker thread pool at the peak of the system. Assuming that the server takes an average of 5ms per request, there can be 200 rps per second for one thread and 800rps per second for a 4-core cpu. Now if there are 4 requests coming in at the same time, then 4 threads will be busy, that is, in the next 5ms, these threads will be busy. So for this 4-core cpu system, the maximum rps is 800.

When the value of acceptCount is set too small, when the number of requests is large, the operating system cannot establish more connections to tomcat (three-way handshake cannot be completed), and there are many connect timeout on the client side, and these rejected requests may be within the processing capacity of the worker thread.

When http keep alive is turned on, the client side may not close the connection so timely, so the server side worker thread will always be occupied by these connections that may not be active in fact, resulting in the worker thread not being reused. However, when http keep alive is closed, tcp connections and ports are frequently made, which will result in a lot of TIME_WAIT socket and increase pressure on the server.

MaxThreads value adjustment (Default 200)

  • Experience values range from 200 to 800, and can be adjusted from 400

  • Represents the maximum number of concurrent requests

  • When the cpu utilization rate is high, it is not appropriate to increase the number of threads, and the value can be reduced.

  • When the cpu utilization rate is not high, and most operations are io blocking classes, this value can be appropriately increased

connectionTimeout(The default value is 60000 milliseconds)

  • The experience value is 2000-60000, and the default 60 seconds may be too high for a web server and can be set to 3000.

  • Actually refers to the value of the SO_TIMEOUT parameter.

  • Represents the maximum interval between the arrival of two tcp packets when blocking reads and writes.

  • This value can be increased when the client is slow.

  • This value can be lowered when a fast timeout is required

doc