Tomcat thread pool

The maximum number of thread connections allowed for Web server is also subject to the kernel parameter settings of the operating system , typically Windows - about,Linux it 's a few or so.

1. Edit the Server.xml file under the Conf directory in the Tomcat installation directory In the <connector/> Configuration in Tomcat configuration file Server.xml, the parameters related to the number of connections are: maxthreads= "150" indicates that up to 150 connections are processed at the same time, and Tomcat uses threads to process each request received. This value represents the maximum number of threads that Tomcat can create. The default value is 200.
Minsparethreads= "25" means that even if no one is using it, open so many empty threads waiting
maxsparethreads= "75" means that if you can empty up to 75 threads, such as 80 people at a time, and no one has access after that, Tomcat does not keep 80 empty threads, but turns off 5 empty. (Once you create a thread that exceeds this value, Tomcat shuts down the socket thread that is no longer needed.) The default value is 50.
）

acceptcount= "100" when the number of simultaneous connections reaches MaxThreads, the number of connections queued can also be received, and the connection will be returned directly to the denied connection. (Specifies the number of requests that can be placed in the processing queue when any number of threads that can be used to process requests is used, and requests that exceed this number will not be processed.) The default value is 10. ) The parameters associated with the maximum number of connections are maxthreads and Acceptcount. If you want to increase the number of concurrent connections, both parameters should be increased.
The maximum number of connections allowed by Web server is also subject to the kernel parameter settings of the operating system, usually Windows is about 2000, and Linux is about 1000. Examples of configurations in TOMCAT5:
<connector port= "8080"
maxthreads= "minsparethreads=" maxsparethreads= "75"
Acceptcount= "/>"
The listening configuration for the other ports, and so on.  

A thread pool typically has three important parameters:
1. Maximum number of threads. The total number of threads does not exceed this number at any time when the program is running. If the number of requests exceeds the maximum number, it waits for the other threads to finish before processing.
2. Maximum number of shared threads, which is the maximum number of idle threads. If the current number of idle threads exceeds this value, the extra threads are killed.
3. Minimum number of shared threads, which is the minimum number of idle threads. If the current idle number is less than this value, the number of idle threads is created at once, so it is itself a step in the creation thread.

The thread pool has two concepts:
1. Worker thread. The worker thread is primarily run execution code, and there are two states: idle and run state. In an idle state, it is similar to "hibernate", Waiting for a task, while processing the running state indicates that the task is running (Runnable).
2. Worker threads. It is primarily responsible for monitoring the status of the thread pool: whether the idle thread exceeds the maximum number of idle threads or less than the minimum number of idle threads. If the requirements are not met, adjust them.

What's the matter with a thread pool? In fact, the thread pool principle is very simple, similar to the concept of buffer in the operating system, its flow is as follows: Start a number of threads, and let these threads are asleep, when the client has a new request, will wake up a thread pool of a sleep thread, let it handle the client's request, When the request is processed, the thread is asleep again. Maybe you might ask: why bother if I create a new thread whenever the client has a new request? This may be a good idea because it makes it easier for you to write code, but you ignore an important question?? Performance! Take my unit, my unit is a centralized data center of the bank network, the peak of the client requests per second more than 100 concurrent, if you create a new thread for each client request, then the CPU time and memory will be amazing, if the use of a thread pool with 200 threads, That would save a lot of system resources, allowing more CPU time and memory to handle real business applications, rather than frequent thread creation and destruction.

After introducing the thread pools for Tomcat, jetty, and resin three Java Web containers, it is customary to compare their pros and cons with each other. But first summarize the characteristics of the thread pool.

The thread pool is widely used as a scheme to improve the ability of process processing data. A large number of servers are more or less used in the thread pool technology, whether in Java or C + + implementation, the thread pool has the following characteristics: There are three key parameters:
1. Maximum number of threads. The total number of threads does not exceed this number at any time when the program is running. If the number of requests exceeds the maximum number, it waits for the other threads to finish before processing.
2. Maximum number of shared threads, which is the maximum number of idle threads. If the current number of idle threads exceeds this value, the extra threads are killed.
3. Minimum number of shared threads, which is the minimum number of idle threads. If the current idle number is less than this value, the number of idle threads is created at once, so it is itself a step in the creation thread.
The thread pool has two concepts:
1. Worker thread. The worker thread is primarily run execution code, and there are two states: idle and run state. In an idle state, it is similar to "hibernate", Waiting for a task, while processing the running state indicates that the task is running (Runnable).
2. Worker threads. It is primarily responsible for monitoring the status of the thread pool: whether the idle thread exceeds the maximum number of idle threads or less than the minimum number of idle threads. If the requirements are not met, adjust them.

1. Modify the memory parameters at startup and specify the JVM time zone (8 hours less in Windows Server 2008):

When running the Java EE Project code on tomcat, a memory overflow is often encountered, and the workaround is to add system parameters to the system parameters:

window, at the front of the Catalina.bat:
Set java_opts=-xx:permsize=64m-xx:maxpermsize=128m-xms512m-xmx1024m;-duser.timezone=gmt+08;
Must be at the front of the Catalina.bat.

Under Linux, add at the front of the catalina.sh:

Java_opts= "-xx:permsize=64m-xx:maxpermsize=128m-xms512m-xmx1024m-duser.timezone=asia/shanghai"

Note: The difference between the front and back, there is no set, there are matchless quotes.

2. Thread pool configuration (TOMCAT6)

Using a thread pool to handle more access with fewer threads can improve the ability of Tomcat to process requests. How to use:

First of all. Open/conf/server.xml, add

<executor name= "Tomcatthreadpool" nameprefix= "catalina-exec-"
maxthreads= "minsparethreads=" maxidletime= "60000"/>

Maximum thread 500 (general server sufficient), minimum number of idle threads 20, maximum thread idle time 60 seconds.

Then, modify the <connector ...> node to add executor properties, such as:

<connector executor= "Tomcatthreadpool"
port= "80"

Protocol= "http/1.1"

maxthreads= "600"

minsparethreads= "100"

maxsparethreads= "300"
Connectiontimeout= "60000"
keepalivetimeout= "15000"
maxkeepaliverequests= "1"
redirectport= "443"
....../>

Maxthreads:tomcat the maximum number of threads that can be created, and each thread processes a request;

Minsparethreads: The minimum number of standby threads, the number of threads initialized at Tomcat startup;

Maxsparethreads: Maximum number of spare threads, once the thread is created that exceeds this value, Tomcat shuts down the socket thread that is no longer needed;

Acceptcount: Specifies the number of requests that can be placed into the processing queue when all the threads that can be used to process the request are used, that is, the number of requests that are queued, and requests that exceed this number will reject the connection.

connnectiontimeout: Network connection time-out, unit: milliseconds. Set to 0 to never time out, so the setting is hidden. It can usually be set to 30000 milliseconds.
Enablelookups: Whether DNS queries are allowed

Note: You can have multiple connector public 1 thread pools.

3, adjust the parameters of connection related connector:

<connector executor= "Tomcatthreadpool"
Port= "protocol=" http/1.1 "
Connectiontimeout= "60000"
keepalivetimeout= "15000"
maxkeepaliverequests= "1"
redirectport= "443"
Maxhttpheadersize= "8192" uriencoding= "UTF-8" enablelookups= "false" acceptcount= "+" disableuploadtimeout= "true"/ >

Parameter description:

• connectiontimeout -Network connection timeout, in milliseconds. Set to 0 to never time out, so the setting is hidden. It can usually be set to 30000 milliseconds.
• keepalivetimeout -Maximum hold Time (milliseconds) for long connections. Here is 15 seconds.
• maxkeepaliverequests -Maximum number of connections (1 is disabled, 1 means no limit, and 100 is the default). Generally set between 100~200) the maximum number of HTTP requests that can be held in the pipeline until the connection are closed by the Server. Setting this attribute to 1 disables http/1.0 keep-alive, as well as http/1.1 keep-alive and pipelining. Setting This to-1 allows an unlimited number of pipelined or keep-alive HTTP requests. If not specified, this attribute is set to 100.
• maxhttpheadersize -The maximum amount of HTTP request header information that is not processed by parts exceeding this length. General 8K.
• uriencoding -Specifies the URL encoding format for the Tomcat container.
• Acceptcount -Specifies the number of requests that can be placed into the processing queue when all the threads that can be used to process the request are used, and requests that exceed this number will not be processed, with a default of 10. Defines the maximum queue length for incoming connection requests if all possible request processing threads is in use. Any requests received if the queue is full is refused. The default value is 10.
• Disableuploadtimeout -whether to use a timeout mechanism when uploading
• enablelookups -whether to reverse the domain name, the value is: TRUE or false. To improve processing power, set to False
• buffersize -Defines the size (in bytes) of the buffer to being provided for input streams created by this connector . By default, buffers of 2048 bytes is provided.
• maxsparethreads -Number of idle connections, once a thread is created that exceeds this value, Tomcat shuts down the socket thread that is no longer needed the maximum number of unused request processing Threads that is allowed to exist until the thread pool starts stopping the unnecessary threads. The default value is 50.
• MaxThreads -The maximum number of simultaneous connections, Tomcat uses the thread to process each request received. This value represents the maximum number of threads that Tomcat can create. The maximum number of request processing threads to being created by this Connector, which therefore determines the maximum n Umber of simultaneous requests that can be handled. If not specified, this attribute is set to 200.
• minsparethreads -The minimum number of idle threads, the number of threads created when Tomcat was initialized the. Processing threads that is created when this Co Nnector is first started. The connector would also make sure it has the specified number of idle processing threads available. This attribute should is set to a value smaller than, set for MaxThreads. The default value is 4.
• minprocessors -The minimum number of idle connection threads used to improve system processing performance, with a default value of 10. (used in TOMCAT4)
• maxprocessors -The maximum number of connection threads, that is, the maximum number of requests that are processed concurrently, and the default value is 75. (used in TOMCAT4)

Note:

TOMCAT4 can be used to control the number of threads by modifying the values of Minprocessors and maxprocessors.

The tomcat5+ is mainly adjusted for the following parameters
MaxThreads
Tomcat uses threads to process each request that is received. This value represents the maximum number of threads that Tomcat can create.
Acceptcount
Specifies the number of requests that can be placed in the processing queue when all the threads that can be used to process the request are used, and requests that exceed this number will not be processed.
Connnectiontimeout
Network connection time-out, unit: milliseconds. Set to 0 to never time out, so the setting is hidden. It can usually be set to 30000 milliseconds.
Minsparethreads
The number of threads created when Tomcat was initialized.
Maxsparethreads
Once you create a thread that exceeds this value, tomcat closes the socket thread that is no longer needed.

Original http://blog.chinaunix.net/uid-12115233-id-3358004.html

Tomcat thread pool