Tomcat performance tuning
Go to the conf directory in the Tomcat root directory and modify the contents of the server. XML file. For this part of the tuning, I know is nothing more than to set the maximum number of concurrent Tomcat server Settings and Tomcat initialization to create the number of threads, of course, there are some other performance tuning Settings, the following is based on the performance of my machine set some parameter values, for you to explain it in detail:
URIEncoding= “UTF-8” : Set the Tomcat character set. We usually don’t set this configuration, because we will deal with garble conversion in a project-specific manner, and it is too rigid to modify the Tomcat character set directly.
MaxThreads = “300” : Set the maximum number of concurrent Tomcat threads. By default, Tomcat supports a maximum of 150 concurrent requests. However, in practice, the maximum concurrency is closely related to hardware performance and CPU quantity. Better hardware and higher processors will enable Tomcat to support more concurrency. Clustering of application servers is generally considered in real development when an application has more than 250 concurrent applications.
MinSpareThreads = “50” : Set the number of threads to be created during Tomcat initialization. The default value is 25.
4. AcceptCount = “250” : When the number of simultaneous connections reaches the maxThreads parameter value, the maxThreads connection is rejected. Specifies the number of requests that can be placed in the processing queue when any number of available processing threads are in use. Requests exceeding this number are not processed. The default value is 100. In practice, if you want to increase the number of concurrent Tomcat applications, you should increase the acceptCount and maxThreads values.
EnableLookups = “false” : indicates whether to enable domain name reverse lookup. The value is generally set to “false” to improve the processing capability. Its value can also be “true” and is rarely used.
6, maxKeepAliveRequests = “1” : Nginx dynamically transfers to tomcat. Nginx cannot keepalive, and tomcat has keepalive enabled by default. It waits for keepalive timeout. Therefore, tomcat timeout must be set and Keepalive for Tomcat must be disabled. Otherwise, a large number of Tomcat socket timewaits are generated.
MaxKeepAliveRequests = “1” prevents Tomcat from generating a large number of TIME_WAIT connections, thus avoiding Tomcat’s feigned death to a certain extent.
JVM performance tuning
Tomcat itself runs on the JVM, and by tweaking the JVM parameters we can get better performance for Tomcat. Currently, there are two main aspects of JVM tuning: memory tuning and garbage collection policy tuning.
First, memory tuning
Go to the bin directory in the Tomcat root directory and set the JAVA_OPTS variable in the catalina.sh file, because JAVA_OPTS will be used as the startup parameter of the JVM. Java virtual machine memory structure is a bit complex, I believe many people in understanding is very abstract, it is mainly divided into heap, stack, method area and garbage collection system, etc. Several parts, the following is my memory structure map from the Internet:
Memory tuning, is nothing more than by modifying their respective size of memory space, so that the application can be more reasonable use, the following is the parameter I set according to the performance of my machine, to give you a detailed explanation of the meaning of each parameter:
-XMx512m: Set the maximum available memory size of the Java VM heap, in MB (m). The total heap size = the size of the young generation + the size of the old generation + the size of the persistent generation. The persistent generation is generally of a fixed size of 64M. The different distribution of heap will have certain influence on the system. As far as possible, the objects are reserved for the new generation to reduce the number of GC in the old generation (usually the old generation is slow to collect).
In practice, it is common to set the initial and maximum values of the heap equal to each other to improve program performance by reducing the number of garbage collections and space extensions that occur while the program is running.
-xMS512m: Sets the initial memory size of the Java VIRTUAL machine heap, in megabytes (m). This value can be set to the same as -xmx to avoid memory reallocation after each garbage collection.
-xmn170m: Set the memory size of the young generation, in MB (m). This value has a great impact on system performance. Sun officially recommends setting it to 3/8 of the entire heap. Generally, after increasing the memory of the young generation, the size of the old generation will also be reduced.
-xss128K: Set stack size for each thread. After JDK5.0, each thread stack size is 1M, before each thread stack size is 256K. The size of memory required by more applied threads is adjusted.
Reducing this value generates more threads for the same physical memory. However, the operating system has a limit on the number of threads in a process, which cannot be generated indefinitely. The experience value is about 3000~5000.
5. -xx :NewRatio=4: Set the ratio of young generation (including Eden and two Survivor zones) to old generation (excluding persistent generation). If set to 4, the ratio of young generation to old generation is 1:4, and the young generation accounts for 1/5 of the entire stack.
6, -xx :SurvivorRatio=4: sets the size ratio of Eden zone to Survivor zone in the young generation. If set to 4, the ratio of two Survivor zones to one Eden zone is 2:4, and one Survivor zone accounts for 1/6 of the whole young generation.
-xx :MaxPermSize=16m; -xx :MaxPermSize=16m; -xx :MaxPermSize=16m
8. -xx :MaxTenuringThreshold=0: Set the garbage maximum age.
If set to 0, the young generation object passes through the Survivor zone and goes directly to the old generation. For the older generation of more applications, can improve efficiency.
If you set this value to a large value, young generation objects will be copied multiple times in Survivor zones, increasing the lifetime of the object in the young generation and increasing the probability that it will be reclaimed in the young generation.
Second, garbage collection strategy optimization
Go to the bin directory in the Tomcat root directory and set the JAVA_OPTS variable in the catalina.sh file. We all know that Java virtual machines have a default garbage collection mechanism, but different garbage collection mechanisms have different efficiency, which is why we often adjust the Java virtual machine garbage collection strategy accordingly. Here are also garbage collection policies configured with some of my requirements:
Garbage collection strategies for Java virtual machines are generally divided into serial collector, parallel collector, and concurrent collector.
Serial collector:
1, – XX: + UseSerialGC: Represents the garbage collection strategy for the serial collector, that is, in the whole scanning and replication process using a single thread to carry out, suitable for single CPU, the generation of small space and the pause time is not very high application, is the client level default GC mode, mainly before JDK1.5 garbage collection mode.
Concurrent collector:
-xx :+UseParallelGC: indicates that the garbage collection policy is parallel collector (throughput first), that is, the whole scanning and replication process is carried out in a multi-threaded way, suitable for multi-CPU applications that require short pause time, which is the default GC mode adopted at the server level. This configuration is valid only for the young generation. This configuration only allows the young generation to use concurrent collections, while the old generation still uses serial collections.
2, -xx :ParallelGCThreads=4: The number of threads that can be used to collect garbage at the same time. This value is best configured to be equal to the number of processors.
3. -xx :+UseParallelOldGC: Set the garbage collection mode of the aged generation to parallel collection. JDK6.0 supports parallel collection for older generations.
-xx :MaxGCPauseMillis=100: Sets the maximum time for each young generation garbage collection. If this time cannot be met, the JVM automatically adjusts the young generation size to meet this value.
5. -xx :+UseAdaptiveSizePolicy: After setting this option, the parallel collector will automatically select the size of the young generation region and the proportion of Survivor regions to achieve the minimum corresponding time or collection frequency specified by the target system. It is recommended to keep the parallel collector open when using it.
Concurrent collector:
-xx :+UseConcMarkSweepGC: indicates that the garbage collection policy is concurrent collector.
Well, that’s all I have to say about the virtual machine garbage collection strategy, again: the learning of optimization is always on the way, and here’s a picture stolen from another blog that says all three GC mechanisms need to work together.
conclusion
This interview question is divided into 19 modules, which are as follows: Java Basics, Containers, multithreading, reflection, object copy, Java Web, exceptions, Networking, Design patterns, Spring/Spring MVC, Spring Boot/Spring Cloud, Hibernate, MyBatis, RabbitMQ, Kafka, Zookeeper, MySQL, Redis, JVM. Concern public number: programmer Bai Nannan