Tomcat Memory configuration Optimization

Considering this scenario, you have developed an application that has excellent layout design, the latest features, and other outstanding features. But in terms of performance this is lacking, regardless of how the application will be rejected by customers. Customers always expect their applications to have better performance. If you use a Tomcat server in your product, this article will give you several ways to improve the performance of your Tomcat server. Thank ITWorld article for providing resources for this article. After meditation I've learned that the latest Tomcat offers better performance and stability than earlier versions. So always use the latest version of Tomcat. Now this article uses the following steps to improve the performance of the Tomcat server.

1. Increase JVM heap memory size

2. Repairing JRE Memory leaks

3. Thread pool Settings

4. Compression

5. Database Performance Tuning

6. Tomcat Local Library

7. Other options

First step – Increase JVM stack memory increase JVM heap memories

If you have used Tomcat, simply say "memory overflow". Typically, this problem occurs in the actual production environment. This problem arises because Tomcat uses less memory for the process by configuring the Tomcat configuration file (Catalina.bat under Windows or catalina.sh under Linux) can solve this problem. This workaround is implemented by increasing the JVM's stack memory. That is, the JVM usually does not call the garbage collector, so the server can focus more on processing the Web request and require it to be completed as soon as possible. To change the file (catalina.sh) located in "\tomcat Server folder\bin\catalina.sh", below, give the configuration information for this file,

1.java_opts= "-djava.awt.headless=true-dfile.encoding=utf-8

2.-server-xms1024m-xmx1024m

3.-xx:newsize=512m-xx:maxnewsize=512m-xx:permsize=512m

4.-XX:MAXPERMSIZE=512M-XX:+DISABLEEXPLICITGC "

Xms– specifying the size of the JVM initialization heap
-xmx– Specifies the maximum value of the JVM heap
The size of these two values is generally set as needed. The size of the initialized heap performs the amount of memory requested by the virtual machine to the system at startup. Generally speaking, this parameter is not important. However, some applications in the case of heavy load will take up more memory, when this parameter is very important, if the virtual machine is set up when the memory is relatively small and in this case there are many objects to initialize, the virtual machine must repeatedly increase the memory to meet the use. For this reason, we generally put-xms and-xmx are set to the same size, and the maximum value of the heap is limited by the physical memory used by the system. Applications that use large amounts of data generally use persistent objects, and memory usage can grow rapidly. The virtual machine prompts for memory overflow when the application needs more memory than the heap, and causes the app service to crash. thereforeThe general recommended heap maximum value is set to the maximum available memory 80%。

Tomcat can use 128MB of memory by default, and in larger applications, this memory is not enough and needs to be scaled up.

Under windows, under File {Tomcat_home}/bin/catalina.bat,unix, in front of file {tomcat_home}/bin/catalina.sh, add the following settings:

java_opts= '-xms ' Initialize memory size "-XMX" maximum memory that can be used "'

you need to increase the value of this two parameter. For example:

java_opts= '-xms256m-xmx512m '

indicates that the initialized memory is 256MB and the maximum memory that can be used is 512MB.

Another thing to consider is the garbage collection mechanism provided by Java. The heap size of a virtual machine determines the time and frequency at which the virtual machine spends collecting garbage. The rate at which garbage collection can be accepted is related to the application and should be adjusted by analyzing the time and frequency of actual garbage collection. If the heap size is large, then the total garbage collection will be slow, but the frequency will be reduced. If you match the size of the heap to the needs of the memory, it will be collected very quickly, but more often. The purpose of sizing the heap is to minimize garbage collection time to maximize processing of customer requests over a specific time period. In benchmarking, to ensure the best performance, the size of the heap to be large, to ensure that garbage collection does not occur throughout the baseline test process.

If your system spends a lot of time collecting garbage, reduce the heap size. A complete garbage collection should be no more than 3-5 seconds. If garbage collection becomes a bottleneck, you need to specify the size of the generation, check the detailed output of the garbage collection, and investigate the performance impact of garbage collection parameters. Generally speaking, you should use 80% of the physical memory as the heap size. When adding processors, remember to increase the memory because allocations can be done in parallel, and garbage collection is not parallel.

These configuration changes will not be valid until you restart your Tomcat server. The following describes how to handle the JREMemory Leaks.

Step Two – Troubleshoot JRE memory leaks

Another major cause of poor performance is memory leaks, as I said before: Always use the latest Tomcat server for better performance and scalability. Now, this sentence becomes true. This error can be resolved if we use the latest Tomcat version 6.0.26 and above, because it contains a listener to handle the memory leaks of the JRE and PermGen. The listener used is ,

1. <listener classname= "Org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
   
   

You can find the configuration of this listener in the Server.xml file,server.xml location in "Tomcat Project Folder/conf/server.xml". Next, we'll look at how to adjust the Connection property "MaxThreads".

Step three – Thread pool settings

The thread pool specifies the number of Web request payloads, so this section should be handled with care to get better performance . You can complete the setup by adjusting the connector properties "MaxThreads". The value of the MaxThreads should be based on the size of the traffic, if the value is too low, there will not be enough threads to handle all requests, the request will go to the waiting state, and only if one of the processing threads is released, and if the setting is too large, Tomcat will take more time to start. So it depends on us setting a correct value for MaxThreads .

1. <connector port= "8080" address= "localhost"

2. maxthreads= "" Maxhttpheadersize= "8192"

3. Emptysessionpath= "true" protocol= "http/1.1"

4. Enablelookups= "false" redirectport= "8181" acceptcount= "100"

5. connectiontimeout= "20000" disableuploadtimeout= "true"/>

In the above configuration, the MaxThreads value is set to "250", which specifies the maximum number of concurrent requests that can be processed by the server. If not specified, the default value for this property is "200". Any additional concurrent requests will receive a "Deny connection" error until another processing request process is released. The error looks like this,

1.org.apache.tomcat.util.threads.threadpool logfull Severe:all Threads (+) are

2.currently busy, waiting. Increase MaxThreads (+) or check the servlet status

If the application prompts the above error, it is important to check whether the above error is caused by a single request that takes too long, and sometimes the process will not process other requests if the database connection is not released.

Note:if the number of requests exceeds "750", this will not mean that the MaxThreads property value is set to "750", it is unexpectedly best to use multiple instances of the Tomcat cluster. That is, if there is a "1000" request, two Tomcat instances are set to "Maxthreads= 500", and maxthreads=1000 is not set in the case of a single Tomcat instance.

Based on my experience, the exact values can be set by testing the application in various environments. Next, let's look at how to compress the MIME type.

4th Step-Compression

Tomcat has an option to set the compression in the Server.xml configuration file . Compression can be done in connector like the following settings,

1. <connector port= "8080" protocol= "http/1.1"
   
   

2. connectiontimeout= "20000"

3. Redirectport= "8181" compression= "500"

4. Compressablemimetype= "Text/html,text/xml,text/plain,application/octet-stream"/>

In the previous configuration, compression occurs when the file size is greater than or equal to 500bytes. If the file reaches the size but is not compressed, the setting property compression= "on". Otherwise, the Tomcat default setting is "off". Next we'll look at how to tune the database.

Fifth Step-database Performance tuning

Tomcat performance is degraded while waiting for database queries to be executed. Most applications today use relational databases that may contain named queries. If that is the case, Tomcat will load the named query by default at startup, which may improve performance. Another important thing is to make sure that all database connections are shut down correctly. It is also important to set the correct values for the database connection pool. The value I refer to is the maximum idle number (maxidle) of the resource feature, the maximum number of connections (maxactive), and the maximum value of the connection wait time (maxwait) attribute. Because of configuration dependencies and application requirements, I cannot specify the correct values in this article. You can find the correct value by calling the database performance test.

6th Step –tomcat Native Library

Tomcat's native library is based on the Apache Portable runtime (Apache portable runtime abbreviation APR), providing programmers with superior scalability and performance, helping to fuse native server technology to deliver optimal performance in product operations. For friends who want to know the installation instructions, refer to Tomcat Native library– (APR) installation.

7th Step – Other options

These options are:

• Open the browser's cache so that reading static content stored in the WebApps folder will be faster, greatly boosting overall performance.

• The tomcat server should restart automatically whenever it is powered on.

• In general, HTTPS requests are slower than HTTP requests. If you want better security, even slower we still have to choose HTTPS.

Tomcat Memory configuration Optimization