tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: asking advice for tomcat 7 config
Date Wed, 17 Oct 2012 09:49:29 GMT
Pid wrote:
...

>>   
>> 	<Executor  name="tomcatThreadPool" namePrefix="catalina-exec-80-" maxThreads="650"
minSpareThreads="100" />
>> 	<Connector executor="tomcatThreadPool" address="10.10.10.10" port="80" maxHttpHeaderSize="8192"
protocol="org.apache.coyote.http11.Http11NioProtocol"
>>            connectionTimeout="20000" redirectPort="443" server="lighthttpd/2.0.0"
enableLookups="false" acceptorThreadCount="4" socket.directBuffer="false" 
>> 		   compression="off" compressableMimeType="text/html,text/xml,text/plain,text/javascript,text/css,image/jpeg,image/png,image/gif"
>> 		   acceptCount="50" bufferSize="4096" />  
>>
>>      
>> 	<Executor  name="stomcatThreadPool" namePrefix="catalina-exec-443-" maxThreads="650"
minSpareThreads="100" />
>>     <Connector executor="stomcatThreadPool" protocol="org.apache.coyote.http11.Http11NioProtocol"
port="443" SSLEnabled="true" scheme="https" secure="true"
>> 	    clientAuth="false" sslProtocol="TLS" keystoreFile="D:\keystore\appks" server="lighthttpd/2.0.0"
>> 		enableLookups="false" keystorePass="changeit" address="10.10.10.10" acceptorThreadCount="4"
socket.directBuffer="false"
>> 		compression="off" compressableMimeType="text/html,text/xml,text/plain,text/javascript,text/css,image/jpeg,image/png,image/gif"
>> 		acceptCount="50" bufferSize="4096" >
>> 	</Connector>
> 
> You've configured a separate pool for connectors on ports 80 and 443.  Why?
> 
> You've reduced the acceptCount to 50.  Why?
> 
> You are compressing compressed images.  Why?

There is : compression="off" in both connectors though.
So I guess that compressableMimeType should be ignored.

(It /is/ still questionable to have changed the default of compressableMimeType, to 
include types which are inherently compressed already.)

> 
> You are setting acceptorThreadCount=4.  Why?
> 
> 
> Does your app have a database connection pool?
> What are the sizing parameters for this pool?
> 
> 
Also,

- for the HTTP connector, connectionTimeout is set to 20000 (milliseconds), and 
keepAliveTimeout is not set.
- for the HTTPS connector, neither one is set.
That will cause :
- for the HTTP connector :
   - connectionTimeout = 20000 ms (20 s.)
   - keepAliveTimeout =  20000 ms
- for the HTTPS connector :
   - connectionTimeout = 60000 ms (60 s.)
   - keepAliveTimeout =  60000 ms

1) So it means that if a client connects to the server, but does not send any request line

for a while on that connection, the server will allocate a thread to serve the request; 
this thread will wait up to 20 s (on HTTP) or 60 s. (on HTTPS), before timing out and 
returning to the pool of available threads.
Of course only a malicious client would do that..

2) it also means that a perfectly non-malicious client can connect to the server, and send

a first request on the connection; the server will allocate a thread to handle this 
request; and then, if the same client has no more requests to send for a while, this 
thread will nevertheless remain waiting on this connection for 20 s. (HTTP) or 60 s. 
(HTTPS), just in case the client /would/ send another request on it.
During this time, the thread is unavailable to process other client requests.

Discarding item (1) for now as being a DOS attack, might (2) not go a long way to explain

the symtoms that the OP is mentioning ?

I would try setting :
- for the HTTP connector :
   - connectionTimeout = 5000 ms (5 s.)
   - keepAliveTimeout =  5000 ms
- for the HTTPS connector :
   - connectionTimeout = 5000 ms (5 s.)
   - keepAliveTimeout =  5000 ms

on the premises that :
- a genuine well-intentioned client is very unlikely to establish a connection with a 
webserver, and then not send any request on that connection for all of 5 seconds
- if a client, after making a first request and having obtained the response to it, is 
then not making any further request to the server on the same connection for more than 5 
seconds, it probably means that he has for now nothing more to request.  And it is not the

overhead of establishing a new TCP connection later that is nowadays going to penalise the

client or the server.
And this would allow these Tomcat threads to be recycled much faster, instead of just 
sitting there doing nothing.

Is that analysis wrong ?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message