Tomcat MaxThreads, Acceptcount (maximum number of threads, maximum number of queues)

The connector configuration for Tomcat 6 is as follows

<connector port= "8080" protocol= "http/1.1"
               connectiontimeout= "20000"
               Redirectport= "8443"
               maxthreads= "acceptcount=" "1000"/>

The last two parameters have the following meanings:

Maxthreads:tomcat the maximum number of threads to start, that is, the number of simultaneous tasks, with a default value of 200

Acceptcount: The number of queued requests is accepted when the number of Tomcat start threads reaches maximum, the default value is 100

How these two values work, see the following three scenarios

Scenario 1: Accept a request, at which time the number of Tomcat start threads does not arrive maxthreads,tomcat will start a thread to process the request.

Scenario 2: Accept a request, when the number of Tomcat start threads has arrived Maxthreads,tomcat will put this request into the wait queue and wait for the idle thread.

Situation 3: Accept a request, at this time the number of Tomcat start thread has reached MaxThreads, waiting for the number of requests in the queue has reached Acceptcount, at this time Tomcat will directly reject this request, return connection refused

MaxThreads How to configure

General server operations include the amount of: 1 calculation (mainly CPU consumption), 2 waiting (IO, database, etc.)

The first extreme case, if our operation is pure calculation, then the system response time is the main limit is CPU computing power, at this time maxthreads should be set as small as possible, reduce the number of threads in the same time to scramble for the CPU, can improve computational efficiency, improve the overall processing capacity of the system.

The second extreme case, if our operation is purely IO or database, then the main response time limit will become waiting for external resources, at this time maxthreads should be set as large as possible, so as to improve the number of processing requests at the same time, so as to improve the overall processing capacity of the system. In this case, you need to focus on Tomcat's virtual machine memory settings and Linux's open file restrictions because the amount of requests that Tomcat can handle at the same time is large.

I encountered a problem in the test, maxthreads I set the larger such as 3000, when the number of threads to a certain degree of service, usually in the early 2000, a single request response time will increase dramatically,

Baffled by this is why, looking around for the answer fruitless, finally I summed up the reason may be the CPU on-line switching time consuming as the number of threads increased,

The CPU has spent most of its time switching directly over more than 2000 threads, and of course the CPU has no time to process our programs.

Previously has been simple to think multithreading = high efficiency. In fact, multithreading itself can not improve CPU efficiency, too much thread will reduce CPU efficiency.

When the CPU core number < thread count, the CPU needs to switch back and forth directly from multiple threads to ensure that each thread gets CPU time, which is usually what we call concurrent execution.

So the MaxThreads configuration is definitely not the bigger the better.

In real-world applications, our operations will include the above two types (calculation, wait), so the MaxThreads configuration does not have an optimal value, must be configured according to the specific circumstances.

The best way is: on the basis of continuous testing, continuous adjustment, optimization, in order to get the most reasonable configuration.

Acceptcount configuration, I usually set the same size as maxthreads, this value should be mainly based on the application of the peak and average access to balance the configuration.

If set smaller, you can guarantee that the accepted request is faster, but the excess request may be rejected directly

If set larger, there may be a large number of request timeouts, because our system processing capacity is certain.