SoFunction
Updated on 2025-04-08

Tomcat configuration and optimization solution detailed explanation


Configuration files are used to configure the entire container in relation to the configuration.

<Server> element:

is the root element of the entire configuration file. Represents the entire Catalina container.

property:

  • className: The class name of the interface is implemented, and the standard implementation class is a class.
  • Port: Tomcat server listens for commands to shut down Tomcat server (must)
  • Shutdown: A command sent to a port to shut down the Tomcat server.

example:

<Serverport=”8005” shutdown=”SHUTDOWN”>

<Connector> element:

The connector is responsible for receiving customer requests and sending response messages back to the client.

HTTP Connector:

property:

  • allowTrace: Whether to allow HTTP TRACE method, default is false
  • emptySessionPath: If set to true, all paths of the user will be set to /, default to false.
  • enableLookups: Call request and getRemoteHost() to execute DNS query to return the host name of the remote host. If set to false, the IP address will be directly returned.
  • maxPostSize: Specifies the maximum amount of requests for POST mode, and the default is 2097152 without specifying.
  • protocol: The value must be HTTP1.1, if using an AJP processor, the value must be AJP/1.3
  • proxyName: If this connector is used in a proxy configuration, specify this property and return it in ()
  • redirectPort: If the connector does not support SSL requests, if the SSL request is received, the Catalina container will automatically redirect the specified port number and let it process it.
  • scheme: Set the name of the protocol, return when (), the SSL connector is set to "https", default to "http"
  • Secure: In the SSL connector, it can be set to true, default to false
  • URIEncoding: Character encoding used to decode URLs, no default value is specified as ISO-8859-1
  • useBodyEncodingForURI: mainly used in Tomcat4., indicating whether to use the encoding specified in contentType to replace URIEncoding, used to decode URI query parameters, default to false
  • xpoweredBy: When true, Tomcat uses the specification suggested header to indicate that the specification version of Servlet is supported, and the default is false
  • acceptCount: The maximum number of requests queued in the queue when all possible threads are in use. When the queue is full, any received request will be denied, the default value is 10
  • bufferSize: Suppose the size of the input stream buffer created by the connector, in bytes. By default, the size of the cache area is 2048 bytes
  • compressableMimeType: The list of MIME, separated by commas by default. The default values ​​are text/html, text/xml, text/plain
  • compression: Specifies whether to compress the response data. off: means prohibited compression, on: means allow compression (text will be compressed), force: means compressed in all cases, the default value is off
  • connectionTimeout: Sets the timeout value of the connection in milliseconds. The default value is 60000=60 seconds
  • disableUploadTimeOut: Allows the Servlet container to execute using a longer connection timeout value to allow the Servlet to have a longer time to complete its execution. The default value is false
  • maxHttpHeaderSize: The maximum amount of HTTP request and response headers, in bytes, the default value is 4096 bytes
  • maxKeepAliveRequest: The maximum number of pipelines sent by the client before the server is closed. The default value is 100
  • maxSpareThreads: The maximum number of free threads allowed, the default value is 50
  • minSpareThreads: Suppose the number of threads created by the connector for the first time, make sure that at least so many free threads are available. The default value is 4
  • port: The TCP port number of the server socket monitor, the default value is 8080 (required)
  • socketBuffer: Set the size of the Socket output buffer (in bytes), -1 means buffering is prohibited, the default value is 9000 bytes
  • toNoDelay: When true, performance can be improved. The default value is true
  • threadPriority: Set the priority of request processing threads in the JVM. The default value is NORMAL-PRIORITY

example:

<Connector 
port="8080" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false"
redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" />

AJP connector:

Used to integrate Apache with Tomcat, when Apache receives a dynamic content request, the request is sent to the AJP connector component listening on this port number through the port number specified in the configuration.

property:

  • backlog: The maximum number of requests queued in the queue when all possible request processing threads are in use. Default is 10, and when the queue is full, any request will be denied
  • maxSpareThread: The maximum number of free threads allowed, the default value is 50
  • maxThread: Maximum number of threads, default value is 200
  • minSpareThreads: Suppose the number of threads created when the connector is first started, ensuring that at least so many free threads are available, the default value is 4
  • port: TCP port number of server socket, default value is 8089 (required)
  • topNoDelay: When true, performance can be improved, the default value is true
  • soTimeout: timeout value

example:

<!—Define an AJP1.3 Connector on port 8089-->
<Connector port=”8089” enableLookups=”false” redirectPort=”8443” protocol=”AJP/1.3” />

<Engine> Element:

Process all requests for a specific service. Each Service can only contain one Engine element, which is responsible for receiving and processing requests received by all connectors of this Service, sending back a response to the connection, and finally displaying it on the client. <Engine> has at least one <Host> element, and at least one <Host> attribute must have the name of the name specified by defaultHost.

property:

  • className: implements the interface, the default implementation class is class
  • defaultHost: The default host name, the value must match the name value of <Service>
  • name: Specify the logical name of the Engine (must)
  • jvmRoute: The identifier used in load balancing must be unique

example:

<Engine name=”Cataline” defaultHost=”localhst”>

<Host> Element:

Represents a virtual host that processes all requests for a specific virtual host

property:

  • appBase: Set the application's base directory, absolute path or path name relative to %CATALINA_HOME%
  • autoDeploy: Instructs whether it is automatic deployment when Tomcat is running. If there is a new WEB program that adds the directory specified by appBase, the default value is true.
  • className: The class that implements the interface, the standard implementation class is a class
  • deployOnStartup: When Tomcat starts, whether to automatically deploy all WEB applications in the specified directory with the default value of true
  • name: The network name of the virtual host (must)

Additional properties supported by standard Host implementation classes:

  • deployXML: false will not resolve the WEB application internals, the default value is true
  • unPackWARs: The virtual host specifies the path name of the directory used for temporary read and write. If not, Tomcat will provide a suitable directory under the %CATALINA_HOME%/work directory.

example:

<Host name=”localhst” appBase=”webapps” unpackWARs=”true” autoDeploy=”true” xmlValidation=”false” xmlNamespaceAware=”false”>

Configure the virtual host:

<Hostname=”xxx” appBase=”c:/test”>
<Contentpath=”” docBase=”e:/abe”/>
</Hostname>

<context> element:

A WEB application that processes all requests from the current WEB application, and each <Context> must use a unique context path.

property:

  • className: class that implements interface, standard implements class class
  • cookies: Whether to apply cookies to Session, default value is true
  • crossContext: Whether to allow cross-domain access, when true, calling the() method in the program will return the request scheduler for other web programs on a virtual host. The default value is false, and the diameter is adjusted with getContext() to return as null
  • docBase: Absolute path or relative path relative to the appBase property of Host
  • privileged: To true, allow web applications to use container servlets
  • path: Specify the context path. In a virtual host, the context path must be unique
  • reloadable: Tomcat runs, if there is any change in the WEB-INF/classes and WEB-INF/lib directories, Tomcat will automatically reload the WEB application. Although it is convenient, it is also expensive. The default value is false. We can turn it on when we call it and close it after it is published.
  • cacheMaxSize: The maximum value of the static resource cache, in KB, the default value is 10240KB
  • cacheAllowed: Whether to allow static resource caching, default is true
  • caseSensitive: Default is true, resource file name is case sensitive, if false case insensitive
  • unpackWAR: default is true
  • workDir: Specify the directory path name for temporary read and write to the servlet inside the WEB application. If not set, Tomcat will provide a suitable directory under the %CATALINA_HOME%/work directory

example:

<Content path=”/abc” docBase=”d:/xyz” reloadable=”true” />

Tomcat performance optimization solution sorting

Consider this scenario, you have developed an application that has very excellent layout design, latest features and other excellent features. However, there is a lack of performance and no matter how this application is, it will be rejected by customers. Customers always expect their applications to have better performance.

If you use Tomcat server in your product, this article will give you several aspects to improve the performance of Tomcat server. Thanks to ITWorld article for providing resources for this article. After meditation I already know that the latest Tomcat offers better performance and stability compared to earlier versions. So I've been using the latest Tomcat version. Now this article uses the following steps to improve the performance of Tomcat server.

  • Increase the JVM heap memory size
  • Fix JRE memory leak
  • Thread pool settings
  • compression
  • Database performance tuning
  • Tomcat local library
  • Other options

Step 1 – Increase JVM heap memory

If you have used tomcat, it is simply "memory overflow". Usually, this problem occurs in an actual production environment. The reason for this problem is that tomcat uses less memory to the process, and this problem can be solved by configuring the TOmcat configuration file (in Windows or under Linux). This solution is achieved by increasing the stack memory of the JVM. That is to say, the JVM usually does not call the garbage collector, so the server can pay more attention to processing web requests and require it to be completed as soon as possible. To change the file() located in "\tomcat server folder\bin\", below, the configuration information for this file is given.

JAVA_OPTS="-=true -=UTF-8
-server -Xms1024m -Xmx1024m
-XX:NewSize=512m -XX:MaxNewSize=512m -XX:PermSize=512m
-XX:MaxPermSize=512m -XX:+DisableExplicitGC"
-Xms – Specify initialization-timed stack memory
-Xms – Specify initialization-timed stack memory
-Xmx – Specify maximum stack memory

These configuration changes will only work after restarting your Tomcat server. The following will introduce how to deal with JRE memory leaks.

Step 2 – Solve JRE memory leaks

Another major reason for poor performance is memory leaks, as I said before: Always use the latest tomcat server for better performance and scalability. Now, this sentence has become 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 memory leaks in JRE and PermGen. The listener used is,

<Listener className="" />

You can find the configuration of this listener in the file, located at "tomcat project folder/conf/". Next, we will see how to adjust the connection property "maxThreads".

Step 3 – Thread Pool Settings

Thread pool specifies the number of web request loads, so this part should be handled with care in order to obtain better performance. Settings can be done by adjusting the connector property "maxThreads". The value of maxThreads should be based on the size of the traffic. If the value is too low, there will be no enough threads to process all requests. The request will enter a waiting state and will only be processed after a processing thread is released; if the setting is too large, the startup of Tomcat will take more time. So it depends on us setting a correct value to maxThreads.

<Connector port="8080" address="localhost"
maxThreads="250" maxHttpHeaderSize="8192"
emptySessionPath="true" protocol="HTTP/1.1"
enableLookups="false" redirectPort="8181" acceptCount="100"
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 of this property is "200". Any extra concurrent requests will receive a "Connection Denied" error prompt until another process of processing requests is released. The error looks like this,

 logFull SEVERE: All threads (250) are
currently busy, waiting. Increase maxThreads (250) or check the servlet status

If the application prompts the above error, be sure to check whether the above error is caused by the fact that a single request takes too long. The reason for this problem is that sometimes if the database connection is not released, the process will not process other requests.

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

In my experience, the setting of the exact value can be obtained by testing the application in various environments. Next, let's take a look at how to compress MIME types.

Step 4 - Compression

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

 <Connector port="8080" protocol="HTTP/1.1"
 connectionTimeout="20000"
 redirectPort="8181" compression="500"
 compressableMimeType="text/html,text/xml,text/plain,application/octet-stream" />

In the previous configuration, the file size is compressed only when it is greater than or equal to 500bytes. If the file reaches the size but is not compressed, then set the attribute compression="on". Otherwise, the default setting of Tomcat is "off". Next we will see how to tune the database.

Step 5 - Database Performance Tuning

Tomcat performance will degrade while waiting for the database query to be executed. Most applications today use relational databases that may contain "named queries". If that is the case, Tomcat will load named queries by default at startup, which may improve performance. Another important thing is to make sure all database connections are closed correctly. It is also very important to set the correct value for the database connection pool. The value I am talking about refers to the maximum number of idles (maxIdle), maximum number of connections (maxActive), and maximum connection wait time (maxWait) attributes of the Resource feature. Because of configuration dependencies and application requirements, I cannot specify the correct value in this article either. You can find the correct value by calling database performance tests.

Step 6 – Tomcat native library

Tomcat's native library is based on Apache Portable Runtime (APR for short), providing programmers with super scalability and performance, helping to integrate native server technology in product operations to show the best performance. For those who want to know the installation instructions, please refer to Tomcat Native Library – (APR) Installation.

Step 7 – Other Options

These options are:

  • Turn on the browser's cache, so that the static content stored in the webapps folder will be faster, greatly promoting overall performance.
  • Whenever the Tomcat server is turned on, the Tomcat server should automatically restart.
  • Generally speaking, HTTPS requests will be slower than HTTP requests. If you want better security, we still need to choose HTTPS even if it is slower.

Setting TOMCAT to enable GZIP compression

Introduction to the principle

HTTP compression can greatly improve the speed of browsing websites. Its principle is that after the client requests the corresponding resources of the server, the resource file is compressed from the server and then output to the client. The client's browser is responsible for decompressing and browsing.

Compared with the normal browsing process HTML, CSS, Javascript, and Text, it can save about 40% of traffic. More importantly, it can also compress web pages generated dynamically, including CGI, PHP, JSP, ASP, Servlet, SHTML, etc., and the compression efficiency is also very high.

Configuration method

The versions of Tomcat5.0 and later support compression of output content, using the gzip compression format.

Modify %TOMCAT_HOME%/conf/, and modify the node as follows:

<Connector port="80" protocol="HTTP/1.1" 
connectionTimeout="20000" 
redirectPort="8443" executor="tomcatThreadPool" URIEncoding="utf-8" 
compression="on" 
compressionMinSize="50" noCompressionUserAgents="gozilla, traviata" 
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" />

As can be seen from the properties of the node above, to use the gzip compression function, you need to add the following properties to the Connector node

  • compression="on" Turn on compression function
  • compressionMinSize="50" Enable compressed output content size, default is 2KB
  • noCompressionUserAgents="gozilla, traviata" No compression enabled for the following browsers
  • compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" Which resource types need to be compressed

Test Method

After enabling the compression function of TOMCAT, how do we test whether the compression is effective?

First of all, Tomcat determines whether the browser supports compression function based on the accept-encoding in the browser request header. If this value contains gzip, it means that the browser supports browsing gzip compressed content. We can use two methods to verify whether the compression is effective.

You directly access the server with compression configuration enabled through the browser, and then view the captured data packets through the packet capture tool. If there are many contents you can't understand, it means that the compression function has been enabled.

Simulate requests through program

We use httpclient to write a simple test program with the following code:

@Test 
public void testGzip() { 
HttpClient httpClient = new HttpClient(); 
GetMethod getMethod = new GetMethod("http://localhost/"); 
try { 
("accept-encoding", "gzip,deflate"); 
("user-agent","Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar; Maxthon 2.0)"); 
int result = (getMethod); 
if (result == 200) { 
(()); 
String html = (); 
(html); 
(().length); 
} 
} catch (HttpException e) { 
(); 
} catch (IOException e) { 
(); 
} finally { 
(); 
} 
}

Execute this junit program to see what it outputs. If the output is some garbled code and the length of the printed content is much smaller than the actual length, it means that our configuration has taken effect. Through some other verification tools, you will find that the website browsing speed will be significantly improved.

Note: If you find that the content is not compressed, you can consider adjusting the compressionMinSize size. If the requested resource is less than this value, compression will not be enabled.

The above is all the content of this article. I hope it will be helpful to everyone's study and I hope everyone will support me more.