tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: How to get the number of "keep-alive" connections ?
Date Mon, 30 Apr 2018 19:56:26 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

André,

On 4/30/18 12:12 PM, André Warnier (tomcat) wrote:
> Hi.
> 
> On 30.04.2018 12:46, Svetlin Zarev wrote:
>> Hi,
>> 
>> The MBean "Catalina:type=ThreadPool,name="http-nio-8080"" has an 
>> attribute called "keepAliveCount" but instead of the keep-alive
>> connections it returns the sum of the number of the pollers'
>> selection keys (as a result it usually reports a low number in
>> the range 0-4 in my test setup). The closest thing to that count
>> is "connectionCount" from the protocol handler, but it counts
>> both keep-alive and non keep-alive connections.
>> 
>> So, is "keepAliveCount" just a bad naming/bug, or am I missing 
>> something ? What's the proper way to track the number of
>> "keep-alive" connections ?
>> 
> 
> That's an interesting question.
> 
> The first part of the answer is probably that for the TCP level of
> the connection, there is no such thing as a "keep-alive
> connection". There are only (to simplify a bit) "established
> connections".

In this case, "keep-alive" almost certainly means "HTTP Keep-alive"
which means that the TCP connection is still up AND the server is
waiting for more requests on the open connection.

> The notion of "keep alive" is only a HTTP-level thing, and it just
> means that, rather than immediately closing this client-server
> connection after sending a response to the client, the server is
> going to keep this connection open (established) for a while, just
> in case the client decides to send a new request on the same
> connection. And in case the client does not send another request on
> the same connection before the "keep-alive timeout" runs out, the
> server will /then/ close that connection.
> 
> And the server does that (I mean wait before closing), only if the 
> client specifically asked for such a keep-alive connection, when it
> sent its first request on the connection. (Otherwise, by default,
> the server /would/ close the connection after sending the first
> response).

The default for HTTP 1.1 connections is that keep-alive should be
enabled. That is, in the absence of a "connection" header from either
the client or the server (in the response, of course), the connection
is assumed to be remaining open.

> All this to say that, from the server perspective, the "number of 
> current keep-alive connections" is probably not as straighforward
> as it may seem. Such as : should it be the total number of client
> connections currently established, no matter what they are doing
> (*) ? or should one subtract from that, the number of these
> connections which are currently linked to a process which is
> processing a request ?

And it gets more complicated when servlet-async is involved, or
Websockets.

> And the corresponding proper naming of a variable which would
> contain this number, is probably just as contentious.

Agreed: there is probably a way to get the count of "keep-live
connections", but what is the real objective, here?

Connections in the keep-alive state only consume a little bit of
resources to keep them open when using an NIO-based I/O model, so you
won't likely run out of threads, but you could run out of TCP ports.
If that's happening, you need more hardware :)

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlrndOkACgkQHPApP6U8
pFi71xAAtCmWtpdRm8GKUg9Z8mcT5dmBD2w19Uj/z/7mGjlx8hLpdX7TQggT2zw1
tOaD7hyZIdDwJHpnWw1jD5waznGX1oEXzvBFKEbHU40wtxuIkV4MA/hjOU+N/FhT
qDEVPgeQS3mMyIQJA2hpzpIxBEOCfmLtx8IYEWiyLexeHhbcJsGaf+fyRwNRQok5
u5IS5YActBY0SoRuiSQBQkTAtcntJQ4ADenciQCXXXeOA2F54SsEZO2+keBcqaZ5
HDAif1o3VLCcjxnzycXXbtgOWKoHBL5gqiteLOy/MaPe+xbDqK6xJ9wOzzLPFb+y
sTBTFVR2nwQ6zASIXD4nG7uSNOsaSnBo1yebEeSGSZ89+R2j8hycUhgVHzNnqRT6
Ax/Th6Kt0vjpt/MuL5NrNWKSv2UdWQw3m4JkNnQFv0sAQv1jbDdOi01Y6XGwr0Hv
YkFz2DZKbPJ20yvZ9T1CgeiPr2rLVjPDhyVsQQQWyeB+g59RWHDfWX7RNa0hAP8R
NGeCefMm5yVrLTAfLFWoj9Zprk9OBPPsVgCmMxwkSoVeoow/Ef1hDlGu0pE+hz0Z
gcq49+ucPLVUiL28J9t/LCk4cz9fCJu3J9cU1aRecRHMuOJVO7ueJcxJaNQ5OQd8
S8aJgRqSJxNevuhJRb2A/c0xBxBi7G1SnoCqxHn1hXpXs/vxUak=
=S8A/
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message