Tomcat important parameter tuning

One. 3 parameters to get the concurrent configuration

As a web container that can undertake high concurrent Internet requests, the first to bear the brunt is of course the impact of massive requests. Fortunately, Tomcat supports NIO, and we can adjust the number of threads and concurrency configuration to make it show the best performance.

  • maxThreads — the maximum number of threads that tomcat receives client requests, that is, the number of simultaneous processing tasks, its default size is 200; generally speaking, in highly concurrent I/O-intensive applications, this value is set to 1000 Left and right are more reasonable

  • maxConnections This parameter refers to the maximum number of connections that tomcat can accept at the same time. For Java’s blocking BIO, the default value is the value of maxthreads; if a custom Executor is used in BIO mode, the default value will be the value of maxThreads in the executor. For the new Java NIO mode, the default value of maxConnections is 10000, so we generally keep this parameter unchanged

  • acceptCount — When the number of threads reaches the value set above, the maximum number of queues that can be accepted. If this value is exceeded, the request will be rejected. I usually set it to the same size as maxThreads

Briefly explain the relationship between the above three parameters:

The number of connections the system can maintain

maxConnections + acceptCount, the difference is that the connections in maxConnections can be scheduled and processed; the connections in acceptCount can only wait for queuing

The number of requests the system can handle

The size of maxThreads, the number of threads that can actually work.

Happiness index: maxThreads > maxConnections > acceptCount.

Some articles are now full of maxProcessors and minProcessors. But these two parameters have been deprecated since Tomcat5, and have been completely gone since Tomcat 6.

It can only be said that the articles you read may really be published by operators who do not understand technology.

Represented by 8, the specific configuration parameters can be found in:

https://tomcat.apache.org/tomcat-8.0-doc/config/http.html

Second, thread configuration

In terms of concurrency configuration, we can see that we only have minSpareThreads, but not maxSpareThreads. This is because, starting from Tomcat 6, adding Executor nodes, this parameter is useless.

Since the thread is a pool, its configuration meets all the characteristics of the pool.

Refer to:

https://tomcat.apache.org/tomcat-8.0-doc/config/executor.html

  • namePrefix — name prefix for each newly opened thread

  • maxThreads — the maximum number of threads in the thread pool

  • minSpareThreads — the number of threads that are always active

  • maxIdleTime — the idle time of the thread, these threads will be destroyed when the idle time is exceeded

  • threadPriority — the priority of the thread in the thread pool, the default is 5

Third, get the JVM configuration

Tomcat is a Java application, so the configuration of the JVM will also affect its performance. The more important configuration parameters are as follows.

2.1, memory area size

The first thing to adjust is the size of each partition, but this also depends on the garbage collector. Let’s just look at some global parameters.

  • -XX: + UseG1GC First, specify the garbage collector used by the JVM. Try not to rely on the default value to guarantee it, but specify one explicitly.

  • -Xmx sets the maximum value of the heap, generally 2/3 the size of the operating system.

  • -Xms Set the initial value of the heap, generally set to the same size as Xmx to avoid dynamic expansion.

  • -Xmn young generation size, the default young generation accounts for 1/3 of the heap size. In high-concurrency and fast-death scenarios, this area can be appropriately enlarged. Half or half, or more, is fine. But under G1, there is no need to set this value, it will be adjusted automatically.

  • -XX:MaxMetaspaceSize limits the size of the metaspace, generally 256M is enough. This is generally the same as the initial size **-XX:MetaspaceSize** is set to.

  • -XX:MaxDirectMemorySize sets the maximum value of direct memory, and limits the memory requested by DirectByteBuffer.

  • -XX:ReservedCodeCacheSize Set the size of the code storage area after JIT compilation. If you observe that this value is limited, you can increase it appropriately, which is generally enough.

  • -Xss sets the size of the stack, the default is 1M, which is enough.

2.2, memory tuning

  • -XX: + AlwaysPreTouch Initialize all the memory specified in the parameters at startup, the startup time will be slower, but the running speed will increase.

  • -XX:SurvivorRatio The default value is 8. Indicates the ratio of the Eden area to the Survivor area.

  • -XX:MaxTenuringThreshold This value defaults to 6 under CMS and 15 under G1. This value is related to the object promotion we mentioned earlier, and the effect of the change will be more obvious. The age distribution of the object can be printed using **-XX: + PrintTenuringDistribution**. If the size of the next few generations is always the same, it proves that the object after a certain age can always be promoted to the old generation, and the promotion threshold can be set small .

  • Objects whose PretenureSizeThreshold exceeds a certain size will be directly allocated in the old generation. However, this parameter is not used much.

2.3, garbage collector optimization

G1 garbage collector

  • -XX:MaxGCPauseMillis Set the target pause time, and G1 will try its best to achieve it.

  • -XX:G1HeapRegionSize Set the small heap region size. This value is a power of 2, neither too large nor too small. If you don’t know how to set it, keep the default.

  • -XX:InitiatingHeapOccupancyPercent When the entire heap memory usage reaches a certain percentage (the default is 45%), the concurrent marking phase will be started.

  • -XX:ConcGCThreads The number of threads used by the concurrent garbage collector. The default value varies depending on the platform the JVM is running on. Modification is not recommended.

Fourth, other important configuration

Let’s look at a few important parameters configured in Connector.

  • enableLookups — call request, getRemoteHost() to perform a DNS query to return the hostname of the remote host, or return the IP address directly if set to false. This depends on demand

  • URIEncoding — the character encoding used to decode the URL, if not specified, the default value is ISO-8859-1

  • connectionTimeout — connection timeout in milliseconds

  • redirectPort — Specifies the port number to redirect after receiving an SSL transmission request when the server is processing an http request