On Wed, Oct 21, 2015 at 1:03 PM, Christopher Schultz wrote: > Jamie, > > > > Your mostly-default <Connector> will default to a maximum of 200 > incoming connections with 200 threads to handle them. You are only using > 12, so something else must be going on. You have no obvious limits on > httpd, so you are probably using the default there as well > (coincidentally, also in the 200-connection range). > > That's a high connection timeout: 93 seconds (why 93?). Note that the > connectionTimeout sets the amount of time Tomcat will wait for a client > to send the request line (the "GET /foo HTTP/1.1"), not the amount of > time the request is allowed to run -- like for an upload, etc. I usually > lower this setting from the default of 60 seconds to more like 5 or 10 > seconds. Clients shouldn't be waiting a long time between making a > connection and sending a request. > > This timeout also applies to subsequent requests on a keep-alive > connection. So if the browser opens a connection and sends 1, 2, 3 > requests, Tomcat will hold that thread+connection open for 93 seconds > after the last request (assuming the client doesn't terminate the > connection, which it might NOT) before allowing other clients to be > serviced by that thread. This is a BIO-Connector-only behavior. The > NIO/NIO2 and APR connectors don't hold-up the request thread waiting for > a follow-up keep-alive request from a client. >
Thanks for the info. It seems as if connectionTimeout is almost universally misunderstood to mean something like "request timeout," (which is why it had been high--to accommodate things like long responses and file uploads). It seems possible that we could be using up too many threads for too long because of the effect of this long timeout on keep-alives. The only time I can think of that a client would be taking any kind of time between connection and sending the request URI line is if someone is manually interacting (say, via telnet). I'm going to follow your lead and reduce this. I doubt that this is the *sole* culprit, but it *is* something for me to tweak. Thanks, Jamie > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
