Hey I'm facing similar problems too and I guess with a good configuration of my server.xml would be a good start point.
So could kindly share a good Connector configuration in this mail thread? What would that be the best choice in terms of max min threads keep alived timeout configurations ? Thanks in advance! Sent from my iPhone On 18/10/2012, at 07:05, Romain Van der Keilen <romain.vanderkei...@uniway.be> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
