Beware. Ill-thought-through concepts follow.
Okay, poll() has overhead. We know that. Large numbers of descriptors
need to be checked when we call it (same for select(), but it's a
slightly different ballgame in it's own way...let's just think poll()
for the moment).
This gets worse as the server gets busy. Proxy response has a
relationship with the length of the poll-structure...as it gets longer,
response goes downhill....this has the added problem that the
poll-structure gets larger as our response-time gets worse, which is a
cycle that feeds off itself.
What irks me about this process, specifically, is that a lot of that
poll() kernel overhead goes to testing descriptors that are more-or-less
idle....or at least won't return ready-read or ready-write for perhaps
several calls of poll.
So, on to the stupid idea. A poll hierarchy. The idea being to keep
several poll-lists of descriptors, grouped by approximate likelyhood
that they will show ready-read/ready-write when we actually return from
poll().
The topmost group would be descriptors that are high-speed, that is,
that return ready most often. Probably a small list. We poll this list
most frequently. The next group down aren't ready nearly as often, and
we can poll them less frequently than the others.
There are vague similarities to the way the scheduler works with process
priorities, here. Ideally we sort our file-descriptors into groups that
we can poll with differing frequencies, according to how often they are
actually in need of service, minimising the amount of work we're giving
to the kernel for each call of poll(). Then we (hopefully) end up
serving fast servers/clients faster, and the slower ones less frequently
perhaps resulting in more cpu-cycles available to actually spend on
servicing them, rather than testing dead descriptors.
Caveat: Not at all well today. I may be talking out of my hat/nether
regions (strike out that which does not apply).
Does this make sense to anyone? Or am I in a daze?
D
Received on Wed Nov 17 1999 - 17:58:11 MST
This archive was generated by hypermail 2.2.0 : Wed Apr 09 2008 - 12:01:56 MDT