gnath wrote:
Please ignore my previously sent edited configuration. Here is what our
configurations are without editing them :
<Executor name="tomcatThreadPool"
namePrefix="catalina-exec-"
maxThreads="500"
minSpareThreads="50"/>
<Connector enableLookups="false" executor="tomcatThreadPool" port="40080"
protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="40443" address="192.42.24.40"/>
<Connector enableLookups="false" executor="tomcatThreadPool" port="40443"
protocol="HTTP/1.1" SSLEnabled="true"
scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" address="192.42.24.40"
keystoreFile="/usr/bin/keystore" keystorePass="password" />
Please let me know. I appreciate your help in looking into this
I have not gone back to your first message, but from the subject I guess that your concern
is that you think that there are a lot of threads active in Tomcat, as compared to the
number of HTTP requests that your server is receiving.
The following does not in any way mean that you should not follow the other advices, and
verify your assumptions, using the appropriate tools.
But you may also want to have a look at the Connector's keep-alive setting.
connectionTimeout
The number of milliseconds this Connector will wait, after accepting a connection, for the
request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite)
timeout. The default value is 60000 (i.e. 60 seconds) but note that the standard
server.xml that ships with Tomcat sets this to 20000 (i.e. 20 seconds).
keepAliveTimeout
The number of milliseconds this Connector will wait for another HTTP request before
closing the connection. The default value is to use the value that has been set for the
connectionTimeout attribute. Use a value of -1 to indicate no (i.e. infinite) timeout.
In your configuration, you do not use an explicit keepAliveTimeout attribute, so it
defaults to the connectionTimeout, which is 20 seconds.
Imagine that your server receives requests for pages, at the rate of 10 per
second.
And that each page contains 3 embedded thumbnail images. So after the first request for
the page, the browser is going to issue 3 more requests for the embedded images.
By default, the keep-alive is active, which means that this all happens over the same HTTP
(or HTTPS) connection; and since it all happens over the same established connection, it
will also be processed by the same Tomcat thread. Which is all basically all A Good Thing,
because it avoids having to tear down and rebuild connections and threads for each request.
Processing the 4 consecutive requests of the browser is likely to take only a fraction of
a second altogether.
After these 4 requests are served, the keepAliveTimeout starts running, and with your
current settings it does so for 20 seconds. During these 20 seconds, the thread which has
processed the 4 requests keeps waiting, in case the browser has any more requests to send
over the same connection (which it probably has not, because the user is considering his
next move).
1/10th of a second after the first request, another browser also sends a request. Since
the first thread is still busy, a new one is allocated. After a fraction of a second,
that one goes in keepAliveTimeout. And so on.
So all in all, this scenario is allocating new threads at the rythm of 10 per second; and
it is only after the first 20 seconds have gone by, that the timeout of the first thread
expires, that it can close its connection, and return to the pool to process another
browser request. By that time, according to the above scenario, you have about 200 threads
waiting in their keep-alive status, and basically not doing anything.
I am not saying that your scenario matches the above, and only you can
determine that.
But it could explain a high number of threads apparently idle.
So if those idle threads bother you, it may be worth trying an explicit lower
keepAliveTimeout (e.g. 5 s), and monitor the impact.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
