Tomcat Tuning Summary (Tomcat self-optimization, Linux kernel optimization, JVM optimizations)

The tuning of Tomcat itself is a tuning setting for several parameters in Conf/server.xml. The first is to have a deep and clear understanding of the meaning of these parameters. Take tomcat8.5 as an example to explain the parameters.

It is also important to realize that the Tomcat tuning is also subject to the Linux kernel. The Linux kernel also has several parameters that can be tuned for TCP connections.

So we can divide Tomcat tuning into Linux kernel optimizations, Java Virtual Machine tuning, and Tomcat's own optimizations.

One, Tomcat self-optimization 1. MaxThreads : The maximum number of threads created by Tomcat, which is the maximum number of concurrent requests processed concurrently. The default value is

Official website: The maximum number of request processing threads to being created by this Connector, which therefore determines the Maximu M number of simultaneous requests that can be handled. If not specified, this attribute is set to 200. If an executor are associated with this connector, this attribute is ignored as the connector would execute tasks using the Executor rather than an internal thread pool. Note that if a executor is configured any value set for this attribute would be recorded correctly but it'll be reported (e.g via JMX) as-to-make clear, that it's not -1 used.

MaxThreads How to Configure (GO)

General server operations include volume aspects: 1 calculation (mainly CPU consumption), 2 waits (IO, database, etc.)

In the first extreme case, if our operation is purely computational, then the main limitation of the system response time is the computing ability of the CPU, at this time maxthreads should be set as small as possible, reduce the number of threads competing for CPU at the same time, can improve the calculation efficiency, improve the overall processing capacity of the system.

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

I encountered a problem in the test,maxthreads I set the relatively large, such as 3000, when the number of threads of service is large to a certain extent, usually in the early 2000, the response time of a single request will increase sharply,

Best of all, this is why, looking around for the answer is not the result, I conclude that the reason may be that the CPU thread switching time consumption as the number of threads increases more and more large,

The CPU uses most of the time to switch directly over the 2000 + threads, and of course the CPU has no time to process our programs.

Previously it has been simple to think multithreading = high efficiency. In fact, multithreading itself does not improve CPU efficiency, but too many threads will reduce CPU efficiency.

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

So the maxthreads configuration is definitely not as big as the better.

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

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

2. Acceptcount: The maximum number of requests that are queued when Tomcat reaches the maximum number of threads. The default value is

Official website: 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 would be refused. The default value is 100.

How do the two values of maxthreads and acceptcount work?

Scenario 1: Accept a request when the number of threads that Tomcat started does not arrive maxthreads,tomcat will start a thread to process the request.

Case 2: Accept a request, at which time the number of threads that Tomcat started has reached Maxthreads,tomcat will put this request into the waiting queue, waiting for the idle thread.

Scenario 3: When a request is accepted, the number of threads that Tomcat has started has reached MaxThreads, and the number of requests waiting in the queue has reached Acceptcount, and Tomcat rejects the request directly, returning connection refused.

For the 3rd case, after reading an analysis of the causes of the connection timeout problem, the number of requests waiting for the queue may be determined by the Acceptcount parameter, or it may be determined by the Linux kernel parameter net.core.somaxconn.

Association : I see an article on the internet that analyzes the reason why TCP connection timeout is on Linux, and this article mentions a kernel parameter net.core.somaxconn.

I just want to know what is the relationship between Tomcat's Acceptcount and Net.core.somaxconn .

I did an experiment,

1. I set the acceptcount of Tomcat to Net.core.somaxconn and set it to 8192

Then I use the SS-LT command to see that the Send_q value on the port from Tomcat is 3000 visible, which is the value of Acceptcount.

2. I set Tomcat's acceptcount to 10000,net.core.somaxconn set to 8192

Also use the SS-LT command to see the send_q value on the port from Tomcat is 8192, which is the value of Somaxconn.

So, I conclude that the value of the Acceptcount setting is generally less than the Net.core.somaxconn parameter, so that the Acceptcount value will work. Net.core.somaxconn The default value of this parameter is 128, so you need to change this parameter value. The method of changing this value is described later.

Acceptcount How to configure? Go

I usually set the same size as maxthreads, this value should be based primarily on the application's access peaks and averages to weigh the configuration.

If set to a smaller size, you can guarantee that the accepted request will be faster, but the exceeding request may be rejected directly

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

3. MaxConnections

Website:

The maximum number of connections that the server would accept and process at any given time. When this number has been reached, the server would accept, but not process, one further connection. This additional connection is blocked until the number of connections being processed falls below MaxConnections At which point the server would start accepting and processing new connections again. Note that once the limit have been reached, the operating system may still accept connections based on the acceptCount setting. T He default value varies by connector type. For NIO and NIO2, the default is 10000 . For apr/native, the default is 8192 .

Note that for apr/native on Windows, the configured value'll be reduced to the highest multiple of 1024x768 that's less tha n or equal to MaxConnections. This is the done for performance reasons.
If set to a value of of-1, the MaxConnections feature is disabled and connections be not counted.

Maximum number of simultaneous connections allowed by Tomcat

Acceptcount, maxconnections are TCP layer-related parameters.

4.connectionTimeOut : connectiontimeout=10000 is said to establish a socket connection, if the client has not received the fin, there is no data come over, Then this connection must wait until 10s before it can be released, I understand that Tomcat is directly releasing this connection. In milliseconds, the default setting for Server.xml is 20 seconds.

Official website: The number of milliseconds this Connector would wait, after accepting a connection, for the request URI line to Be presented. Use a value of-1 to indicate no (i.e. infinite) timeout. The default value is 60000 (i.e. seconds), but note, the standard Server.xml, the ships with Tomcat sets this to 200 (i.e. seconds). Unless disableuploadtimeout false is set to, this timeout would also be used when reading the request body (if any ).

Modification Method:

VI server.xml Open server.xml file

Will

<!--name= "Tomcatthreadpool" nameprefix= "catalina-exec-" maxthreads= "<executor" minsparethreads= "4"/>- -
Modified to:
  <executor name= "Tomcatthreadpool" nameprefix= "catalina-exec-"        maxthreads= "50" minsparethreads= " Prestartminsparethreads= "true"/>

Will

<connector  port= "8080"  protocol= "http/1.1"  connectiontimeout= "20000"  redirectport= "8443"  />
Revision changed to

<connector executor = "Tomcatthreadpool" port= "8009" protocol= "Org.apache.coyote.http11.Http11Nio2Protocol"  connectiontimeout= "20000" maxconnections= "10000" redirectport= "8443" acceptcount= "/>"  

The following figure is a TCP three-time handshake with accept interaction

The SYN queue is called a half-connection queue and is set by the kernel parameter net.ipv4.tcp_max_syn_backlog.

The Accept queue is called a full-connection queue, and the three-time handshake has been completed but has not yet been received by the application layer (accept), but is also in the established state. The queue length is determined by the listen backlog parameter and the kernel's net.core.somaxconn parameters. specified by the second parameter backlog of the listen () function, the kernel hard limit is limited by net.core.somaxconn, that is, the actual value of the queue length is determined by min (backlog,somaxconn).

The client uses connect to send a TCP connection to the server, and the three-time handshake occurs. When the 1.1-step client sends the SYN to the server first, the kernel puts the connection information into the SYN queue and returns a Syn+ack packet to the client. After some time, after the client sends the ACK packet again, the kernel pulls the connection out of the SYN queue and puts the connection in the Accept queue. When the application server calls accept, it actually pulls the successful connection socket directly from the accept queue.

There is also a diagram of the process and queue in which the TCP handshake establishes the connection

Overview of the Tomcat principle

Tomcat is roughly divided into two parts, connector components and container components. The connector component controls the ingress connection and is associated with a executor. Container is responsible for the implementation of the servlet container, executor is responsible for the specific business logic, such as the execution of the servlet. Once a request arrives at the server, follow these key steps, see:

1. The OS shakes with the client and establishes the connection and puts the established connection into the completion queue, which may be called acceptor queque. The length of this queue is the Acceptcount value of the connector.

2. The acceptor thread in Tomcat constantly gets the connection from the acceptor queque.

3. Acceptor Queque queue is not connected, acceptor thread continues to monitor

4. Acceptor the Queque queue has a new connection, the acceptor thread will check if the current number of connections exceeds the MaxConnections

5. If the maxconnections is exceeded, it is blocked. The request is sent to executor for execution until the number of connections is less than the maxconnections,acceptor thread.

6. Executor will assign the worker thread to handle the read of the request data, the processing (execution of the servlet), and the response.

   Acceptcount

   Acceptcount is actually the backlog value that is passed by the bind socket, meaning that the maximum length of the connection queue that has been established for the connection has not been applied to the Linux platform. At this point, if the number of requests reaches Acceptcount, the new incoming request will throw refuse connection.

Second, Linux kernel parameter optimization 1. Limit on the number of files that Linux systems can open simultaneously for a single process of the current user

To view the limit on the number of files that the system allows the current user process to open: Ulimit-u default value is 1024

For a communication handler that wants to support a higher number of TCP concurrent connections, you must modify the soft limit (soft limit) and the hard limit (hardlimit) of the number of files that Linux has open simultaneously for the current user's process. The soft limit refers to the Linux in the current system can withstand the extent to further limit the number of files opened by the user at the same time; hard limits are the number of files that can be opened at the same time based on the system's Hardware resource status (mainly system memory). The soft limit is usually less than or equal to the hard limit.

Modification Method:

sudo vi/etc/security/limits.conf

Add the following:

Prouser Soft Nofile 65536
Prouser Hard Nofile 65536

Save this file when you are finished modifying it.

2.Linux Network kernel Restrictions on TCP connections Modify the method: sudo vi/etc/sysctl.confAdded as follows: Net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle = 1
Net.ipv4.tcp_fin_timeout =
Net.ipv4.ip_local_port_range = 10000 65000
Net.ipv4.tcp_max_syn_backlog = 8192
Net.ipv4.tcp_max_tw_buckets = 10000

The length of the net.core.somaxconn=8192 accept queue is related to this parameter

sudo/sbin/sysctl-p
Real-time effective third, JVM tuning

java_opts= "$JAVA _opts-server-xmn2000m-xms4000m-xmx4000m-xx:permsize=128m-xx:+useconcmarksweepgc-xx:maxpermsize =512m-djuli-logback.configurationfile=file: $CATALINA _home/conf/logback.xml "

Default value:

<!--name= "Tomcatthreadpool" nameprefix= "catalina-exec-" maxthreads= "<executor" minsparethreads= "4"/>- -

Modified to:

<executor name= "Tomcatthreadpool" nameprefix= "catalina-exec-" maxthreads= "$" minsparethreads= "MaxIdleTime=" "60000" prestartminsparethreads = "true" maxqueuesize = "/>"

Parameter explanation:

maxthreads: Maximum concurrency, default setting of 200, generally recommended at 500 ~ 800, according to hardware facilities and business to judge
minsparethreads: Number of threads created when Tomcat was initialized, default setting 25
maxidletime: If the current thread is greater than the initialization thread, the idle thread survives the time, in milliseconds, by default 60000=60 seconds = 1 minutes.
prestartminsparethreads: Initializes the minsparethreads parameter values when Tomcat is initialized, and if not equal to the value of true,minsparethreads, nothing works.
maxqueuesize: Maximum number of waiting queues, exceeding deny request

5.Connector parameter Optimization configuration

Default value:

<connector  port= "8080"  protocol= "http/1.1"  connectiontimeout= "20000"  redirectport= "8443"  />

Modified to:

<connector executor= "Tomcatthreadpool" port= "8080" protocol= "Org.apache.coyote.http11.Http11Nio2Protocol" Connectiontimeout= "60000" maxconnections= "10000" redirectport= "8443" enablelookups= "false" acceptcount= "100" Maxpostsize= "10485760" maxhttpheadersize= "8192" compression= "on" disableuploadtimeout= "true" compressionMinSize= " 2048 "acceptorthreadcount=" 2 "compressablemimetype=" Text/html,text/plain,text/css,application/javascript, Application/json,application/x-font-ttf,application/x-font-otf,image/svg+xml,image/jpeg,image/png,image/gif, Audio/mpeg,video/mp4 "uriencoding=" Utf-8 "processorcache=" 20000 "tcpnodelay=" true "connectionlinger=" 5 "server=" Server Version 11.0 "/>

Parameter explanation:

Protocol: Tomcat 8 Settings Nio2 better: Org.apache.coyote.http11.Http11Nio2Protocol
Protocol: Tomcat 6 Set NiO better: Org.apache.coyote.http11.Http11NioProtocol
Protocol: Tomcat 8 Sets APR performance fast: Org.apache.coyote.http11.Http11AprProtocol more details:Tomcat 8.5 Performance optimization based on Apache Portable runtime (APR) library》
ConnectionTimeout: Connector the time to wait after a connection is accepted (milliseconds), the default value is 60000.
MaxConnections: This value indicates the maximum number of sockets that can be connected to Tomcat
enablelookups: Disable DNS queries
Acceptcount: When the number of threads started by Tomcat reaches maximum, the number of requests queued is accepted, and the default value is 100.
maxpostsize: Sets the maximum length of the URL parameter resolved by the container, 1 (less than 0) to disable this property, which defaults to 2097152 (2M) Note that the Failedrequestfilter filter can be used to reject requests that have reached the limit value.
maxhttpheadersize: The maximum amount of HTTP request header information that exceeds this length is not processed. General 8K.
Compression: Whether gzip compression on is enabled (text data compression) off is not enabled, force compresses all data
Disableuploadtimeout: This flag allows the servlet container to use a different, usually long data upload connection timeout. If not specified, this property is set to True, which indicates that the time-out is disabled.
compressionminsize: Compressed only when the minimum data size is exceeded
Acceptorthreadcount: The number of threads used to accept connections. Increase this value on multi-CPU machines, although you will never really need more than 2. There are also many non-maintenance connections, and you may want to increase this value. The default value is 1.
Compressablemimetype: Configure the type of data you want to compress
uriencoding: Web sites generally use UTF-8 as the default encoding.
Processorcache: The protocol processor caches the processor objects to improve performance. This setting determines how many of these objects are cached. -1 means infinity, default is 200. If you do not use Servlet 3.0 for asynchronous processing, the default is to use the same maxthreads setting. If you use Servlet 3.0 for asynchronous processing, the default is the maximum number of concurrent requests (synchronous and asynchronous) that use large maxthreads and expected.
Tcpnodelay: If the set to True,tcp_no_delay option will be set on the server socket, and in most cases improve performance. This is the default setting of True.
Connectionlinger: The number of seconds to close when this connector will continue to use the socket. The default value is-1, which disables the socket delay time.
Server: Hide Tomcat version information, first hide version information in HTTP header

6. Hide or modify the Tomcat version number

# cd/usr/local/tomcat/lib/# Unzip Catalina.jar # CD Org/apache/catalina/util # VIM Serverinfo.properties

Server.info=apache tomcat/8.5.16 server.number=8.5.16.0 Server.built=jun 17:01:09 UTC

Remove or modify the version number above.

7. Remove the Disable default administration page and related profiles

 # rm-rf/usr/local/apache-tomcat-8.5.16/webapps/* # rm-rf/usr/local/apache-tomcat-8.5.16/conf /tomcat-users.xml 

reference content:
HTTPS://TOMCAT.APACHE.ORG/TOMCAT-8.5-DOC/CONFIG/
HTTPS://GITHUB.COM/JUDASN/LINUX-TUTORIAL/BLOB/MASTER/TOMCAT-INSTALL-AND-SETTINGS.MD
HTTP://WIKI.JIKEXUEYUAN.COM/PROJECT/LINUX-IN-EYE-OF-JAVA/TOMCAT-INSTALL-AND-SETTINGS.HTML
http://netkiller.github.io/journal/tomcat.html
http://zjliu.me/2015/12/ 14/tomcat-config-connector/

Tomcat Tuning Summary (Tomcat self-tuning, Linux kernel optimization, JVM optimization)