tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jamie Jackson <>
Subject Re: Monitoring Connections
Date Wed, 21 Oct 2015 18:37:47 GMT
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


> -chris
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message