Detailed explanation of Tomcat configuration and optimization solutions

Service.xml

The Server.xml configuration file is used to configure the entire container.

<Server> element:

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

property:

• className: The class name that implements the org.apache.catalina.Server interface. The standard implementation class is the org.apache.catalina.core.StandardServer class.
• Port: Tomcat server listens for commands used to shut down the Tomcat server (required)
• Shutdown: The command sent to the port to shut down the Tomcat server.

example:

<Serverport="8005" shutdown="SHUTDOWN">

<Connector> element:

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

HTTP Connector:

property:

• allowTrace: Whether to allow HTTP TRACE method, the default value is false
• emptySessionPath: If set to true, all paths for the user will be set to /. Defaults to false.
• enableLookups: Call request and getRemoteHost() to perform a DNS query to return the host name of the remote host. If set to false, the IP address is returned directly.
• maxPostSize: Specifies the maximum size of POST requests. If not specified, the default value is 2097152.
• protocol: The value must be HTTP1.1. If the AJP processor is used, the value must be AJP/1.3.
• proxyName: If this connector is being used in a proxy configuration, specify this property, which is returned when request.getServerName() is used
• redirectPort: If the connector does not support SSL requests, if an SSL request is received, the Catalina container will automatically redirect the specified port number for processing.
• scheme: Sets the name of the protocol, returned by request.getScheme(), for SSL connectors set to "https", default is "http"
• secure: This can be set to true in SSL connectors. The default value is false
• URIEncoding: The character encoding used to decode the URL. If not specified, the default value is ISO-8859-1.
• useBodyEncodingForURI: Mainly used in Tomcat4.1.x, indicating whether to use the encoding specified in contentType instead of URIEncoding to decode URI query parameters. The default value is false
• xpoweredBy: When true, Tomcat uses the header recommended by the specification to indicate support for the Servlet specification version. The default value is false
• acceptCount: The maximum number of requests that can be queued in the queue when all possible processing threads are in use. When the queue is full, any received requests will be rejected. The default value is 10
• bufferSize: Sets the size of the input stream buffer created by the connector, in bytes. By default, the maximum buffer size is 2048 bytes.
• compressableMimeType: A list of MIME types, comma-separated by default. The default values ​​are text/html, text/xml, text/plain
• compression: Specifies whether to compress the response data. off: means disabling compression, on: means allowing compression (text will be compressed), force: means compression in all cases, the default value is off
• connectionTimeout: Set the connection timeout value in milliseconds. The default value is 60000 = 60 seconds
• disableUploadTimeOut: Allows the Servlet container to use a longer connection timeout value so that the Servlet has more time to complete its execution. The default value is false
• maxHttpHeaderSize: The maximum size of the HTTP request and response header, 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 idle threads allowed. The default value is 50
• minSpareThreads: Sets the number of threads to be created when the connector is first started, ensuring that at least this many idle threads are available. The default value is 4
• port: The TCP port number that the server socket listens on. The default value is 8080 (required)
• socketBuffer: Set the size of the Socket output buffer (in bytes). -1 means disabling buffering. The default value is 9000 bytes.
• toNoDelay: When true, it can improve performance. The default value is true
• threadPriority: Sets the priority of the request processing thread 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, it sends the request to the AJP connector component listening on the port number specified in the configuration.

property:

• backlog: The maximum number of requests that can be queued when all possible request processing threads are in use. The default value is 10. When the queue is full, any request will be rejected.
• maxSpareThread: The maximum number of idle threads allowed. The default value is 50
• maxThread: Maximum number of threads, the default value is 200
• minSpareThreads: Set the number of threads to create when the connector is first started, ensuring that at least this many idle threads are available. The default value is 4
• port: TCP port number of the server socket, the default value is 8089 (required)
• topNoDelay: When true, it can improve performance. 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:

Handles 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 responses back to the connections, and finally displaying them on the client. <Engine> must have at least one <Host> element, and there must be at least one <Host> attribute with a name that matches the name specified by defaultHost.

property:

• className: implements the org.apache.catalina.Engine interface. The default implementation class is the org.apache.catalina.core.StandardEngine class.
• defaultHost: The default host name. The value must match the name value of <Service>
• name: Specifies the logical name of the Engine (required)
• jvmRoute: Identifier used in load balancing, must be unique

example:

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

<Host> element:

Represents a virtual host and handles all requests for a specific virtual host

property:

• appBase: Set the base directory of the application, absolute path or path name relative to %CATALINA_HOME%
• autoDeploy: Indicates whether to automatically deploy new web programs to the directory specified by appBase when Tomcat is running. The default value is true
• className: The class that implements the org.apache.catalina.Host interface. The standard implementation class is the org.apache.catalina.core.StandardHost class.
• deployOnStartup: Whether to automatically deploy all WEB applications in the directory specified by the appBase attribute when Tomcat starts. The default value is true
• name: The network name of the virtual host (required)

The standard Host implementation class org.apahce.catalina.core.StandardHost supports additional properties:

• deployXML: false will not parse the context.xml inside the WEB application. The default value is true
• unPackWARs: The virtual host specifies the path name of the directory used for temporary reading and writing. If not set, Tomcat will provide a suitable directory in 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 handles all requests for the current web application. Each <Context> must use a unique context path.

property:

• className: class that implements the org.apache.catalina.Context interface, standard implementation class org.apache.catalina.core.StandardContext class
• Cookies: whether to apply Cookie to Session, the default value is true
• crossContext: Whether to allow cross-domain access. When true, calling the ServletContext.getContext() method within the program will return a request dispatcher for other web programs on a virtual host. The default value is false, and getContext() returns null.
• docBase: absolute path or relative path to the appBase property of the Host
• privileged: true, allowing the Web application to use the container's Servlet
• path: specifies the context path. The context path must be unique within a virtual host.
• reloadable: true, when Tomcat is running, if there are changes in the WEB-INF/classes and WEB-INF/lib directories, Tomcat will automatically reload the WEB application. Although it is convenient, the cost is also high. The default value is false. We can turn it on during the call and turn it off after publishing.
• cacheMaxSize: Maximum value of static resource cache, in KB, the default value is 10240KB
• cachingAllowed: Whether to allow static resource caching, the default is true
• caseSensitive: The default value is true, the resource file name is case sensitive, if it is false, it is case insensitive
• unpackWAR: default is true
• workDir: Specifies the temporary read-write directory path name for the Servlet within the WEB application. If not set, Tomcat will provide a suitable directory in the %CATALINA_HOME%/work directory

example:

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

Tomcat performance optimization solution summary

Consider this scenario, you have developed an app with an excellent layout design, latest features and other great features. However, if the performance is lacking, the application will be rejected by customers no matter how good it is. Customers always expect their applications to have better performance.

If you use Tomcat server in your product, then this article will give you several ways to improve the performance of Tomcat server. Thanks to ITWorld article for providing resources for this article. After pondering I have come to know that the latest Tomcat provides better performance and stability compared to earlier versions. So always use the latest Tomcat version. Now this article uses the following steps to improve the performance of Tomcat server.

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

Step 1 – Increase JVM heap memory

If you have used tomcat, it is simply called "memory overflow". Usually, this problem occurs in the actual production environment. The reason for this problem is that tomcat uses less memory for the process. This problem can be solved by configuring the TOmcat configuration file (catalina.bat under Windows or catalina.sh under Linux). This solution is achieved by increasing the stack memory of the JVM. In other words, the JVM usually does not call the garbage collector, so the server can focus more on processing web requests and require them to be completed as soon as possible. To modify the file (catalina.sh) located in "\tomcat server folder\bin\catalina.sh", the following are the configuration information for this file.

JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8
-server -Xms1024m -Xmx1024m
-XX:NewSize=512m -XX:MaxNewSize=512m -XX:PermSize=512m
-XX:MaxPermSize=512m -XX:+DisableExplicitGC"
-Xms – specifies the stack memory to be initialized -Xms – specifies the stack memory to be initialized -Xmx – specifies the maximum stack memory

These configuration changes will not take effect until you restart your Tomcat server. The following describes how to deal with JRE memory leaks.

Step 2 – Fix JRE memory leak

Another major reason for poor performance is memory leaks, and as I said before: always use the latest tomcat server for better performance and scalability. Now, this sentence has become true. If we use the latest tomcat version 6.0.26 and above, we can resolve this error because it includes a listener to handle memory leaks in JRE and PermGen. The listener used is,

<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />

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

Step 3 – Thread Pool Setup

The thread pool specifies the number of web request loads, so this part should be handled carefully for better performance. This 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 not be enough threads to handle all requests, and the request will enter a waiting state and will only be processed when a processing thread is released; if it is set too large, Tomcat will take more time to start. So it depends on us to set a correct value for 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 additional concurrent requests will receive a "connection refused" error until another process is freed to handle the request. The error looks like this,

org.apache.tomcat.util.threads.ThreadPool 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 a single request taking 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 does not mean setting the maxThreads attribute value to '750', it means it is better to use multiple instances of 'Tomcat Cluster'. That is, if there are "1000" requests, both Tomcat instances set "maxThreads = 500", instead of setting maxThreads = 1000 in the case of a single Tomcat instance.

In my experience, the exact value can be found by testing the application in various environments. Next, we'll look at how to compress MIME types.

Step 4 - Compression

Tomcat has an option to enable compression by setting it in the server.xml configuration file. Compression can be done in the connector settings like below,

 <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, files will be compressed only when their size is greater than or equal to 500 bytes. If the file is not compressed when it reaches the required size, set the property compression="on". Otherwise the Tomcat default setting is "off". Next we will look at how to tune the database.

Step 5 - Database Performance Tuning

Tomcat performance will degrade while it waits for database queries to be executed. Most applications today use a relational database that may contain "named queries". In that case, Tomcat will load named queries by default on startup, which may improve performance. Another important thing is to make sure all database connections are closed properly. It is also very important to set the correct value for the database connection pool. The values ​​I am talking about are the values ​​of the maximum idle number (maxIdle), maximum number of connections (maxActive), and maximum connection establishment waiting time (maxWait) attributes of the Resource element. 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.

Step 6 – Tomcat Native Library

Tomcat's native library is based on the Apache Portable Runtime (APR), which provides programmers with superior scalability and performance, and helps integrate native server technology in product operations to demonstrate optimal performance. For installation instructions, please refer to Tomcat Native Library – (APR) Installation.

Step 7 – Other options

The options are:

• Enable browser caching so that static content stored in the webapps folder can be read faster, greatly improving overall performance.
• The Tomcat server should automatically restart at every boot.
• Generally speaking, HTTPS requests are slower than HTTP requests. If you want better security, we should choose HTTPS even if it is slower.

Set TOMCAT to enable GZIP compression

Principle Introduction

HTTP compression can greatly improve the speed of browsing websites. Its principle is that after the client requests the corresponding resources from 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, Text, it can save about 40% of the traffic. More importantly, it can compress dynamically generated web pages, including those output by CGI, PHP, JSP, ASP, Servlet, SHTML, etc., and the compression efficiency is also very high.

Configuration Method

Tomcat 5.0 and later versions support compression of output content, using the gzip compression format.

Modify %TOMCAT_HOME%/conf/server.xml and revise the nodes 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 above nodes, to use the gzip compression function, you need to add the following properties to the Connector node

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

Test Method

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

First, Tomcat determines whether the browser supports compression 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 compression is effective.

You can 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 is a lot of content that you cannot understand, it means that the compression function has been enabled.

Simulate requests through programs

We use httpclient to write a simple test program. The code is as follows:

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

Execute this junit program and see what it outputs. If the output is some garbled characters and the length of the printed content is much smaller than the actual length, it means that our configuration is effective. 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 smaller than this value, compression will not be enabled.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.