When a web application wants to log information about the client, it can either log the client’s numeric IP address or look up the actual host name in the Domain Name Service data. DNS lookups require network traffic, involving a round-trip response from multiple servers, possibly far away and possibly inoperative, resulting in delays. To disable these delays you can turn off DNS lookups. Then, whenever a web application calls the getRemoteHost() method in the HTTP request object, it will only get the numeric IP address. This is set in the Connector object for your application, in Tomcat’s server.xmlfile. For the common java.io HTTP 1.1 connector, use the enableLookups attribute. Just find this part of the server.xmlfile:
<!-- Define a non-SSL HTTP/1.1 Connector on port 8080 --> <Connector port="8080" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="true" redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" />
Just change theenableLookups value from"true"to"false", and restart Tomcat. No more DNS lookups and their resulting delays!
Unless you need the fully qualified hostname of every HTTP client that connects to your site, we recommend turning off DNS lookups on production sites. Remember that you can always look up the names later, outside of Tomcat. Not only does turning them off save network bandwidth, lookup time, and memory, but in sites where quite a bit of traffic generates quite a bit of log data, it may save a noticeable amount of disk space as well. For low traffic sites, turning off DNS lookups may not have as dramatic an effect, but it is still not a bad practice. How often have low traffic sites become high traffic sites overnight?
Adjusting the Number of Threads
Another performance control on your application’s Connector is the number of request handler threads it uses. By default, Tomcat uses a thread pool to provide rapid response to incoming requests. A thread in Java (as in other programming languages) is a separate flow of control, with its own interactions with the operating system, and its own local memory—but with some memory shared among all threads in the process. This allows developers to provide fine-grained organization of code that will respond well to many incoming requests.
You can control the number of threads that are allocated by changing aConnector’sminThreads andmaxThreadsvalues. The values provided are adequate for typical installations but may need to be increased as your site gets larger. TheminThreads value should be high enough to handle a minimal loading. That is, if at a slow time of day you get five hits per second and each request takes under a second to process, the five preallocated threads are all you will need. Later in the day, as your site gets busier, more threads will need to be allocated (up to the number of threads specified inmaxThreadsattribute). There needs to be an upper limit to prevent spikes in traffic (or a denial-of-service attack from a malicious user) from bombing out your server by making it exceed the maximum memory limit of the JVM.
The best way to set these to optimal values is to try many different settings for each and test them with simulated traffic loads while watching response times and memory utilization. Every machine, operating system, and JVM combination may act differently, and not everyone’s web site traffic volume is the same, so there is no cut-and-dry rule on how to determine minimum and maximum threads.
BrainDump 
