Hi there! Some news for you about my problem. I did all the modifications you suggested, it increased the response time a little bit (2-3 seconds better on a 15 seconds scale). It was already good to take, and helped me to create a healthy configuration. After that, I looked deeper into the database configuration, as I saw in the tests that non db relative actions were responding very fast (50ms for a 1000 users basis). I finally found an OracleDataSource in the Oracle Driver, which reacts far way better than the BasicDataSource I was using before (12s for 150 users for the basic data source, 1.5s for the oracle one, same test).
So I think my problems are solved, thanks to you guys! Many thanks for the advices, Romain. -----Original Message----- From: André Warnier [mailto:a...@ice-sa.com] Sent: mercredi 17 octobre 2012 11:49 To: Tomcat Users List Subject: Re: asking advice for tomcat 7 config 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
