Java system performance tuning --tomcat

1. Optimize tomcat memory

The default memory that Tomcat can use is 128MB. In larger application projects, this memory is not enough, which may cause the system to fail to run.

The common problem is to report Tomcat memory overflow error, Out of Memory (insufficient system memory) exception, which causes the client to display a 500 error. Generally, adjusting the memory used by Tomcat can solve this problem.
Modify the "%TOMCAT_HOME%\bin\catalina.bat" file in the Windows environment, and add the following settings at the beginning of the file: set JAVA_OPTS=-Xms256m -Xmx512m In
the Linux environment, modify the "%TOMCAT_HOME%\bin\catalina.sh" file, in the file Add the following settings at the beginning: JAVA_OPTS='-Xms256m -Xmx512m'
Among them, -Xms sets the initial memory size, and -Xmx sets the maximum memory that can be used.

If you check the log, you will find an error message: java.lang.OutOfMemoryError: PermGen space
Reason: The full name of PermGen space is Permanent Generation space, which refers to the permanent storage area of ​​memory. This memory is mainly used by JVM to store Class and Meta information. Class When it is loaded by the Loader, it will be placed in the PermGen space. It is different from the Heap area where the class instance (Instance) is stored. GC (Garbage Collection) will not clean up the PermGen space during the runtime of the main program, so if your application If there are a lot of CLASS, PermGen space error is likely to occur. This kind of error is common when the web server precompiles the JSP. If your WEB APP uses a large number of third-party jars, the size of which exceeds the default size of jvm (4M), then this error message will be generated.

Solution: Add in the first line of catalina.bat:
set JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m
Add in the first line of catalina.sh:
JAVA_OPTS= -Xms64m -Xmx256m -XX:PermSize=128M -XX: MaxNewSize

=256m -XX:MaxPermSize=256m

The related parameters are:
minProcessors: the minimum number of idle connection threads, used to improve system processing performance, the default value is 10
maxProcessors: the maximum number of connection threads, that is: the maximum number of concurrently processed requests, the default value is 75
acceptCount: the maximum allowed connection The number, should be greater than or equal to maxProcessors, the default value is 100
enableLookups: whether to reverse the domain name, the value is: true or false. In order to improve processing power, it should be set to false
connectionTimeout: network connection timeout, unit: milliseconds. Setting it to 0 means that it will never time out, which is a hidden danger. Usually can be set to 30000 milliseconds.
The parameters related to the maximum number of connections are maxProcessors and acceptCount. If you want to increase the number of concurrent connections, you should increase these two parameters at the same time.
The maximum number of connections allowed by the web server is also subject to the kernel parameter settings of the operating system, usually about 2000 for Windows and about 1000 for Linux. How to set these parameters in Unix, see Common Unix Monitoring and Management Commands.
Taking the parameter configuration of tomcat7 as an example, the conf/server.xml file needs to be modified, mainly to optimize the connection configuration and close the client dns query.

<Connector port="8080"  
           protocol="org.apache.coyote.http11.Http11NioProtocol" 
           connectionTimeout="20000" 
           redirectPort="8443"   maxThreads=
           "500"  
           minSpareThreads="20" 
           acceptCount="100"
           disableUploadTimeout="true"
           enableLookups="false"  
           URIEncoding="UTF-8" />The

above two methods are the most commonly used, if it still doesn't work, try the following method



3. Remove the web. xml monitoring, edit jsp into Servlet in advance.



If there is spare physical memory, increase the memory of the jvm used by tomcat 4. Server resources
　　The performance of the CPU, memory, and hard disk that the server can provide has a decisive impact on the processing power.
　　(1) In the case of high concurrency, there will be a large number of operations, so the speed of the CPU will directly affect the processing speed.
　　(2) In the case of a large amount of data processing in the memory, there will be a large memory capacity requirement. You can use parameters such as -Xmx -Xms -XX:MaxPermSize to divide different functional blocks of the memory. We have encountered insufficient memory allocation before, causing the virtual machine to be in full GC all the time, resulting in a serious drop in processing power.
　　(3) The main problem of the hard disk is the read and write performance. When a large number of files are read and written, the disk can easily become a performance bottleneck. The best way is to use the cache mentioned below.


5. Use caching and compression
　　For static pages, it is best to cache them so that you don't have to read them from disk every time. Here we use Nginx as the cache server to cache images, css, and js files, which effectively reduces the access to the backend tomcat.
　　In addition, in order to speed up the network transmission speed, it is also essential to turn on gzip compression. But considering that tomcat already needs to deal with a lot of things, the compression work is handed over to the front-end Nginx to complete.
　　In addition to text can be compressed with gzip, in fact, many pictures can also be pre-compressed with image processing tools, finding a balance point can make the loss of image quality small and the file size can be reduced a lot. I have seen a picture compressed from more than 300 kb to dozens of kb, and I can hardly see the difference.


6. Adopt cluster The performance of
　　a single server is always limited, and the best way is to achieve horizontal expansion, so the establishment of a tomcat cluster is an effective means to improve performance. We still use Nginx as the server for request offloading, and multiple tomcats on the backend share sessions to work together. Of course, it would be better if you use redis to manage sessions manually.


The above steps are mainly aimed at the old projects that are difficult to optimize the architecture and code, and the complexity of the operation is gradually increasing. It is recommended to try them in order.

If it is a new project, performance design should be considered at the beginning of development

Source : http://lib.csdn.net/article/javaweb/6141