Re: [Patch][RFC] epoll and half closed TCP connections

[Jamie Lokier <jamie@shareable.org>]

David, you are point out that given a certain base assumption, namely
that the number of active desriptors is proportional to the number of
inactive descriptors, that epoll does not scale any differently to poll.

Correct.

Davide and I have pointed out that the key difference between
select/poll and epoll, mathematically, is that epoll time is
bounded by the number of active descriptors, and select/poll time is not.

Also correct.

(The latter is a logically stronger statement than the former, because
it has fewer assumptions, however that doesn't make it's increased
range of applicability relevant.)

Now if you look at web server benchmarks and other artificial
benchmarks, rumour has it that epoll-based server CPU usage increases
linearly with load, and pages served increases linearly with the
number of requests, until the point where the server is maxed, after
which both these observables remain roughly constant with increasing
load.

Similar rumours have it that select/poll-based servers CPU usage
increases in the same way, but not only do the observables increase
faster (irrelevent for this discussion), when the server is maxed its
number of pages served decreases (badly) with increasing load.

In this sense, it's useful to refer to epoll as more scalable: not the
linear part at the beginning, but later, when resources are exhausted.

Load here is defined as number of concurrent client connections.  In
fact, the number of active descriptors _is_ less than proportional to
the number of idle descriptors in this state, because the slower
responses act as a form of flow control on the rate of new connections
or new data coming in to the server.

If instead you define a test in terms of increasing the rate of
incoming connections, as if the clients are oblivious to each other,
then your point might be spot on.  But that is a different kind of
test, and it doesn't take away from the validity of the first kind.

-- Jamie