Tomcat Optimization Detailed

Tomcat Optimization Detailed

1. Overview

This document mainly introduces the principle and method of the performance tuning of Tomcat. It can be used as a technical guide for the company's technical staff to tune customer Tomcat systems, and can also be provided to customers ' technicians as a guide to their performance tuning.

2, Tuning classification

Since Tomcat's operation relies on the JVM, from the perspective of the virtual machine we divide Tomcat's adjustment into external environment tuning and self tuning two classes to describe.

-2.1, external environment tuning

Adjusts the operating system parameters of the Tomcat runtime environment and the Java Virtual machine parameters that run tomcat.

--2.1.1, Java Virtual machine performance optimization

Tomcat needs to rely on Java virtual machines to run. Select the corresponding JDK version according to the operating system of the host selected by the customer. Regardless of which manufacturer's JDK, the latest version is recommended.

The virtual machine can change the size of the virtual machine's memory using the command line. As shown in the following table, two parameters are used to set the amount of memory used by the virtual machine.

Parameters and Description:

-XMS JVM Initialization Heap Size

Maximum value of the-xmx JVM heap

Tomcat can use the default memory of 128MB, in larger application projects, this memory is not enough, need to be scaled up.

Windows, tomcat_home/bin/catalina.bat in file;

Under Unix, in front of the file tomcat_home/bin/catalina.sh, add the following settings:

java_opts= '-xms ' initializes the memory size '-xmx ' The 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 initialization memory is 256MB and the maximum memory available is 512MB.

Another thing to consider is the garbage collection mechanism provided by Java. The heap size of the 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 actual time and frequency of garbage collection.

If the heap is large, complete garbage collection (full GC) is slow, but frequency decreases. If the heap size and memory requirements are aligned in the customer system, the collection will be complete quickly, but more frequently.

The purpose of the heap sizing is to minimize the time spent in garbage collection to maximize the processing of customer requests for a specific period of time. For virtual machines such as sun and HP, it is recommended that the minimum heap size and maximum heap size be set to the same value, as this avoids wasting the VM resources needed to adjust the heap size at times.

Of course, if the client system uses an IBM virtual machine, it's important to note that setting the same size as-XMS and-XMX will delay the start of garbage collection until it is full, so that the first garbage collection becomes a very expensive operation. It is recommended that the-XMS be set to the minimum value required for application, resulting in efficient garbage collection.

--2.1.2, operating system performance optimization

Take the customer system as an example of HP-UX.

Parameters that affect Tomcat in the HP system, where:

Max_thread_proc: Maximum number of threads that a process can create

Nkthread: Maximum number of core threads allowed at the same time on the system

Maxfiles the advice given on the table is not inappropriate.

If you see a message in the output: java.lang.OutOfMemoryError:unable to create new native thread, the Unix kernel named Max_thread_proc is set too small. Max_thread_proc is the maximum number of threads in a single process. It must be large enough to accommodate all the threads in the Java application and some extra threads in the virtual machine itself.

View Core parameters: $ulimit-A

The nofiles in the display output refers to the maximum number of file handles that a user's process can open at the same time. If the "Two many open files" exception appears in the log, it is important to check this parameter.

The Coredump parameter is the maximum value of the core file, which limits the size of the core file to the maximum when the process coredump. If the core file is found incomplete when the log file is checked, this parameter value needs to be increased. Execute the ulimit-n command to set the Nofiles parameter and execute the ULIMIT-C command to set the core file maximum value.

If you are using Tomcat on the Windows operating system, it is best to select the server version. The number of end-user authorizations or the number of users that the operating system itself can withstand, the number of network connections available, or some aspects of other aspects are limited on a non-server version. And based on security considerations, the operating system must always be updated with the latest patches.

--2.1.3, tomcat consolidation with other Web servers

Although Tomcat can also be used as a Web server, its handling of static HTML is not as fast as Apache, and its function as a Web server is far less than Apache, so we want to integrate Apache and Tomcat, the HTML and JSP functional parts of the clear division of labor, Let Tomcat handle only the JSP part, others are processed by the Web servers such as Apache,iis, which greatly saves Tomcat's limited worker threads.

-2.2, self tuning

This section describes the techniques and methods of Tomcat performance tuning, regardless of the operating system or the type of Java virtual machine. The following methods are the best way to adjust for Tomcat performance itself.

--2.2.1, disabling DNS queries

When a Web application records the client's information, it also records the client's IP address or converts it to an IP address by looking for the machine name through the domain name server. DNS queries need to occupy the network and include the process of obtaining a corresponding IP from many remote servers or servers that do not work, which can take a certain amount of time.

To eliminate the impact of DNS queries on performance we can turn off DNS queries by modifying the enablelookups parameter values in the Server.xml file.

The different tomcat versions are slightly different:

Tomcat4

<connector classname= "Org.apache.coyote.tomcat4.CoyoteConnector" port= "minprocessors=" "5" maxprocessors= "75" Enablelookups= "false" redirectport= "8443" acceptcount= "debug=" 0 "connectiontimeout=" 20000 " Useurivalidationhack= "false" disableuploadtimeout= "true"/>

Tomcat5

<connector port= "maxthreads=" "minsparethreads=" maxsparethreads= "" enablelookups= "false" Redirectport= "8443" acceptcount= "debug=" "0" connectiontimeout= "20000" disableuploadtimeout= "true"/>

Unless the customer requires the machine name of each HTTP client that is connected to the site, we recommend that the DNS query function be turned off on a production environment. You can get the machine name in a way other than Tomcat. This not only saves network bandwidth, query time and memory, but also smaller traffic will make the log data will become less, obviously also saves the hard disk space. For less-traffic sites, disabling DNS queries may not have the effect of a large traffic site.

-2.2.2, adjust the number of threads

Another parameter that can be controlled by the application's connector (Connector) is the number of threads created to process the request. Tomcat uses a thread pool to speed up response time to process requests. The Java thread is the path of the program at run time, a code snippet that is independent of other control threads in a program and can run independently.

They share the same address space. Multithreading helps programmers write efficient programs that maximize CPU utilization, keeping their idle time to a minimum and accepting more requests.

TOMCAT4 can be used to control the number of threads by modifying the values of Minprocessors and maxprocessors. These values are set to the default values after installation and are sufficient for use, but are scaled up as the site expands. The number of threads created at the Minprocessors server startup should be sufficient to handle a small amount of load. That is, if only 5 click events occur per second in a single day, and 1 seconds for each request task to be processed, a preset number of threads of 5 is sufficient.

However, you need to set a larger number of threads when you visit a large site, specifying the value of the parameter maxprocessors. The value of the maxprocessors is also capped and should prevent traffic from being uncontrollable (or malicious service attacks), resulting in an excess of the amount of memory used by the virtual machine. If you want to increase the number of concurrent connections, both of these parameters should be increased. The maximum number of connections allowed by Web server is also subject to the kernel parameter settings of the operating system, typically Windows is 2000 or so, and Linux is about 1000.

These parameters are adjusted in TOMCAT5, see the following table:

Property name and Description:

Maxthreads:tomcat uses threads to handle each request that is received. This value represents the maximum number of threads that Tomcat can create.

Acceptcount: Specifies the number of requests that can be placed in the processing queue when all available processing requests are used, and requests that exceed this number will not be processed.