Re: TCP connections clogging up accf_http(9)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 25 May 2016 15:31:21 +0200
    From:        Edgar =?iso-8859-1?B?RnXf?= <ef%math.uni-bonn.de@localhost>
    Message-ID:  <20160525133121.GI25206%gumme.math.uni-bonn.de@localhost>

  | > In the case of a server that is broken, and not accepting connections, that's
  | > also clearly what is needed.
  | But without an Accept Filter, those connection requests would also
  | just fill the queue?

Yes, that was the point, the best thing to do when the server is
(for whatever reason) refusing to accept connections is to reject
attempts to make them, just as if the server was not there at all
(which it, effectively, isn't.)

  | I thing tls@'s approach would make all this possible at no cost,
  | wouldn't it?

It certainly allows the server to deal with the connection as it sees
fit, and in the "ordinary" case (the one that provoked this examination)
is likely to work just OK - that is, where there are just occasional
lost connections that gradually build up in the queue because of the
filter, though even there I'd like to observe what happens when this state
is reached, with the 192 connections clogging the queue, and new connections
still arriving - it would probably be better to clear the queue of all the
backlogged crud rather than removing one at a time - while also ignoring
the incoming request that provoked it.

I suspect it might easily happen that by the time the client that is
making the new connection tries again, some other connection will have
occupied the (one) free queue slot, and is working its way to satisfying
the filter - thus causing another old connection to be bumped to the
server, and ignoring the incoming request, again .. perhaps over and over
again.

I also suspect that it kind of defeats the principle objective of the
filters - that is, to lower overhead for really busy servers.  It really
doesn't make a lot of difference for servers that only process a few
connections a second - whether the server, or the kernel, processes the
initial data should not make that much difference.   But with a very busy
server, receiving perhaps thousands of new requests a second, the listen
queue is going to fill very quickly, without allowing time for the filter
to actually do its job.  Clearly the server can then go ahead and process
things itself, but this is defeating the purpose of the filter which is
precisely to allow the server to ignore the connection (consume no resources)
until it has real work to do, which it then ought to be able to complete
very quickly and go away - passing through the connections when the only
reason it is being done is because the load is very high, also seems wrong
to me (that is, I would expect that if filters are in use, sufficient time
should be allowed (a couple of seconds at least) before the connection
(if the filter hasn't finished of course) is ever a candidate for handing
off to the server.   The current fix doesn't allow for that.   When this is
the cause of the queue overflow, the best thing to do is actually to simply
ignore incoming connection requests until the queue level drops (the same
as happens when there is no filter and the queue overflows because of
connections arriving faster than the server can cope over some burst.)

It is certainly a cheap change, and an easy one, but I doubt it is really the
best way.   Obviously better than nothing.   But I believe that to
handle this properly, the code needs to have some concept of time, and
use it.

kre