ok... thanks for nothing... 2012/10/18 Pid <p...@pidster.com>
> 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] > >
