IV. Self-adjustment This section will introduce you to some acceleration skills and methods that allow Tomcat instances to run, no matter what
Operating system or what Java virtual machine. In some cases, you may not have an operating system or Java virtual machine in the deployment environment. In this case, you need to learn from some of the following suggestions, however you should take effect after modification. I think the following method is the best way to adjust the Tomcat performance itself.
Disable DNS query
When the web application is to log information about the client, it also logs the client's IP address or to find the machine name via the domain name server to convert to an IP address. The DNS query needs to take up the network, and includes the process of obtaining the corresponding IP from a lot of far servers or inactivated servers, which will consume a certain amount of time. In order to eliminate the impact of DNS queries We can turn off the DNS query, the way is the enablelookups parameter value in the server.xml file:
Tomcat4
Unless you need to connect to each HTTP client of the site, we recommend closing the DNS query function in the production environment. The machine name can be obtained in a manner 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, and it saves the hard disk space. Disabling DNS queries may not be significant without a large-flow site, but this move is still not a good policy. Who will see a low-traffic website that is increased overnight?
2. Adjust the number of threads
Another parameter that can perform performance control through the application's connector is the number of threads created. Tomcat uses the thread pool to accelerate the response speed to process the request. Threading in Java is the path when the program is running, and is independently running the code segment that is independent of the other control thread in a program. They share the same address space. Multithreading helps programmers write an efficient program for the maximum utilization rate of CPU, allowing idle time to be minimized, thus accepting more requests.
Tomcat4 can be controlled by modifying the value of minprocessors and maxProcessors. These values have been set to the default values after installation and are sufficient to use, but with the expansion of the site. The number of threads that the process requested when the Minprocessors server starts should be sufficient to process a small amount of load. That is, if only 5 clicked events occur within one day, each of the request task processing takes 1 second, then set the number of threads in advance is sufficient. But when your site has a large amount, you need to set a larger thread number, specify the value of the parameter maxprocessors. The value of MaxProcessors is also capable, and the traffic should be prevented from being uncontrollable (or malicious service attack), resulting in the size of the virtual machine to use memory. If you want to increase the number of concurrent connections, you should increase these two parameters. The maximum number of web services allowed is also subject to the operating system's kernel parameter setting, usually Windows is about 2,000, Linux is about 1000. Adjusting these parameters on Tomcat5, see the following table:
Attribute Name Description MaxThreads Tomcat uses threads to process each request received. This value represents the maximum number of threads that Tomcat can create. AcceptCount Specifies that when all the number of threads that can be used is used, you can put the number of requests in the process queue, and the request exceeding this number will not be processed. ConnnectionTIMEOUT network connection timeout, unit: milliseconds. Set to 0 indicates that never timeout, this is set to have hidden dangers. It is usually set to 30000 milliseconds. The number of threads created when MinsPareThreads Tomcat is initialized. Once the MaxSparethreads created exceeds this value, Tomcat will turn off the no longer needed Socket thread.
The best way is to set a few times and test, observe the response time and memory usage. In the case of different machines, operating systems, or virtual machines may differ, and not the traffic of all people's web sites, so there is no one-knife-cut solution to determine the value of the thread.
