On 18/10/2012 12:22, Daniel Barcellos wrote: > 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 ?
It's probably not your connector config that's the problem, if there is one. Most of the time it's your app. Use a profiler, monitor JMX (use VisualVM with the MBeans plugin) and understand what's happening rather than assuming someone else's connector config is "good" or "better". Start a new thread when you've tried this & have questions. p > 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 > -- [key:62590808]
signature.asc
Description: OpenPGP digital signature
