Re: Poll-splitting

Dancer wrote:

> Okay, now _this_ is a little odd....Further to my email about splitting
> poll() structures into groups according to the likelyhood of getting a
> ready-response, I thought..well..hey, tcp connections are buffered in
> the kernel. We can probably get _some_ performance improvement by only
> calling poll on (say) a third to a quarter of the descriptors per pass,
> and letting the kernel buffers take up the slack for the ones we pass
> over until a later poll.

This alos reminds me of OPTIMISTIC_IO in Squid-2.2 (currently removed in
Squid-2.3). The assumption behind OPTIMISTIC_IO is that most of the time
the OS is ready to accept and buffer the data, which I believe is a
valid assumption.

A typical call pattern for a data forwarding operation today is
basically:

0. poll the receiving soket for read
1. Read from the receiving socket
2. Mark the sending socket for poll
3. poll the sending socket for write
4. write to the sending socket
5. Mark the receiving socket for poll
6. poll the receiving socket for read
[now back to 1]

(the exact location of the mark operations differs depending on if the
transmit window is full or not)

With some cleverness it should be possible to effectively cut the number
of filedescriptors polled by 50% by making proper use of TCP
buffers/windows, and to speed up the forwarding latency by one poll
loop.

One simple and generic approach without some of the loop hasards of
OPTIMISTIC_IO (but possibly other problematic properties) is to simply
skip the poll if the last use of the descriptor was not initiated by a
poll on that filedescriptor. Theoretically this could also be used as
throttling factor for server connections: don't poll the server
connection if the frontmost client is waiting for poll

Note that we still need to poll the client filedescriptors for read with
some interval (once every few seconds or so) to support quick_abort on
stalled connections.

(note: this I/O pattern discussion applies to select as well, not
limited to poll)

/Henrik
Received on Mon Nov 29 1999 - 14:53:26 MST