Tomcat corrects Service.xml performance tuning increases maximum concurrent connections __ Tools

1, Tomcat's external tuning
Java Virtual Machine (JVM) performance optimization allows you to set the size of the virtual machine using memory,-xms<size> (JVM initialization heap size) and-xmx<size> (the JVM heap's maximum) with the following two parameters.
The size of these two values is generally set as needed. The size of the initialization heap performs the size of the memory that the virtual machine requests to the system at startup. Generally speaking, this parameter is not important. However, some applications in a large load of the case will be a sharp use of more memory, at this time this parameter is very important, if the virtual machine is set up at the start of 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 set the-XMS and-xmx to be the same size, while the maximum of the heap is limited by the physical memory used by the system. Typically, applications that use large amounts of data use persistent objects, and memory usage is likely to grow rapidly. When the application needs more memory than the maximum of the heap, the virtual machine prompts for a memory overflow and causes the application service to crash. Therefore, the maximum value of the generic recommended heap is set to 80% of the maximum available memory.
Tomcat can use the default memory of 128MB, in larger application projects, this memory is not enough, need to be scaled up.
Under Windows, under File {Tomcat_home}/bin/catalina.bat,unix, in front of the file {tomcat_home}/bin/catalina.sh, add the following settings:
java_opts= '-xms ' Initialize memory size '-XMX ' Maximum memory available '
You need to increase the value of this two parameter. For example: ava_opts= '-xms256m-xmx512m ', which means that the initialization memory is 256MB, 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 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 in size, complete garbage collection can be slow, but the frequency is reduced. If you match the size of the heap with the need for memory, the collection will be complete quickly, but will be more frequent. 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. In the benchmark, to ensure the best performance, the heap size is set to ensure that garbage collection does not occur throughout the benchmark process, if the system spends a lot of time collecting garbage, please 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, examine the verbose output of garbage collection, and study the impact of garbage collection parameters on performance. Generally, you should use 80% of the physical memory as the heap size. When adding the processor, remember to increase the memory, because the allocation can be done in parallel, and garbage collection is not parallel.
2, Tomcat's internal tuning
(i) Prohibit DNS lookup
Sometimes our application may have to record the client's information in two ways, one is to record the digital IP address of the client, and the other is to find the real host name in the DNS data. DNS lookups increase network traffic, resulting in network latency. To eliminate this delay, we can ban DNS lookups. When our application calls the Getremotehost () method, it will only get the numeric IP address. This configuration is the Enablelookups property of the connector object in Tomcat's Serve.xml file, as follows:
<!--
Define a non-sslcoyote http/1.1 Connector on port 8080
-->
<connector
Classname= "Org.apache.coyote.tomcat4.CoyoteConnector"
port= "8080" minprocessors= "5" maxprocessors= "75"
Enablelookups= "true" redirectport= "8443"
Acceptcount= "Ten" debug= "0" connectiontimeout= "20000"
Useurivalidationhack= "false"
/>
In a production system, this is usually a recommended ban unless the application is to get the true hostname of all clients. We can do this kind of work outside of Tomcat. In a small flow of servr the effect of this modification may not be very obvious, but for some sites, perhaps suddenly the flow of sudden increase may also be, for example, some time ago, the Olympic ticketing website, haha.
(ii) Adjustment of the number of threads
Another factor that affects performance is the number of processes used by connector. Tomcat uses a thread pool to increase the speed of the request response. One of the threads in Java interacts with the operating system alone, with its own local memory and shared portions of shared memory with other threads in the process.
We can control the number of threads by modifying the minprocessors and maxprocessors of the connector object. This number may have been set up when it was just on the line, but when the number of users becomes more numerous, we need to increase the number of configurations. The minprocessors value should be set large enough to handle the minimum load. When the user gets more, tomcat allocates more threads, no more than maxprocessors. The upper limit must also be set appropriately so that the server's memory is hung over the JVM's memory limit.
(iii) Accelerate the compilation of JSP
The first time you access the JSP, it will be converted into Java servlet source code, and then compiled into binary. In this process, we are able to control the compiler used. By default, Tomcat uses the same compiler that executes Javac on the command line. In fact, there are faster compilers, we can use these to improve the JSP compile speed.

V. Monitoring of Tomcat servers
1, Tomcat's own monitoring index Servelet
Step one: Increase the user access permissions in the configuration file. Modify the Conf/tomcat-users.xml file to include a line <user username= "username" password= "password" roles= "manager"/>
Step Two: Enter Http://IP address in IE Browser: port number/manager/status
Step three: Enter the user name and password set in the first step in the pop-up dialog box to view the relevant performance metrics data for the application server.
2, the use of specialized tools for monitoring, online a lot of this will no longer repeat.

In the configuration in the Tomcat configuration file Server.xml, the parameters associated with the number of connections are:
Minprocessors: Minimum number of idle connection threads to improve system processing performance with default value of 10
Maxprocessors: Maximum number of connection threads, that is, the maximum number of requests that are processed concurrently, with a default value of 75
Acceptcount: The maximum number of connections allowed, the wait queue, that 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. 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. To improve processing power, set to False
ConnectionTimeout: Network connection timeout, in milliseconds. A setting of 0 means never time out, and this setting is hidden. Typically, it can be set to 30000 milliseconds.
The parameters associated with the maximum number of connections are maxprocessors and Acceptcount. 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.
3, Server.xml Configuration Introduction
The following describes the basic configuration information in this file, and for more specific configuration information, refer to the Tomcat documentation:
Server
1, port to specify a ports, this port is responsible for listening to turn off Tomcat request
2. Shutdown specifies the command string to be sent to the port
Service
1. Name specified service
Connector (indicates the connection between client and service):
1. Port specifies the port number to be created on the server side and listens for requests from the client on this fracture surface
2. Minprocessors the number of threads created at server startup to process requests
3. Maxprocessors the maximum number of threads that can be created to handle requests
4, Enablelookups If true, you can call Request.getremotehost () DNS query to get the actual hostname of the remote client, if False is not a DNS query, but return its IP address
5, Redirectport specified server is processing an HTTP request, received an SSL transfer request redirected after the port number
6. 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
7, ConnectionTimeout specifies the number of times to timeout (in milliseconds)
The number of threads can be calculated roughly by the number of simultaneous user operations per second (number of connections per second) * System average operating time (server processing time).
Engine (represents a request processor in a specified service, receiving and processing requests from connector):
1. defaulthost Specifies the host name of the default processing request, which is at least the same as one of the host element Name property values.
Context (representing a Web application):
1, the path of the Docbase application or the path that the war file holds
2, path represents the prefix of the URL for this Web application, so the URL for the request is
http://localhost:8080/path/****
3, reloadable This property is very important, if true, Tomcat will automatically detect the application of the/web-inf/lib and/web-inf/classes directory changes, automatic loading of new applications, We can change the application without having to restart Tomcat.
Host (represents a virtual host):
1, name specifies the host name
2, appbase application Basic directory, that is, the directory where the application is stored
3, Unpackwars If true, then Tomcat will automatically extract the war file, or not understand the pressure, run the application directly from the war file
Logger (for logs, debugging, and error messages):
1. classname specifies the class name used by logger, which must implement the Org.apache.catalina.Logger interface
2, prefix specifies the log file prefix
3, suffix specify the suffix of log file
4, timestamp If true, the log file name to add time, for example: Localhost_log.2001-10-04.txt
Realm (a database that holds user names, passwords, and role):
1. classname specifies the class name used by realm, which must implement the Org.apache.catalina.Realm interface
Valve (features similar to logger, whose prefix and suffix properties are interpreted as in logger):
1, classname specified valve use of the class name, such as with Org.apache.catalina.valves.AccessLogValve
Class can record access information for an application
Directory (specify where log files are stored):
1, pattern has two values, common

Some of these latest versions are not supported, please refer to: Click to open the link