Re: An attempt at optimising the poll code

On Fri, 4 Aug 2000, Henrik Nordstrom wrote:

> Tricky thing this.. but I am more and more convinced that a priority
> based algorithm is the way to go. The higher the priority, the shorter
> the timeout. And lower priorities should include the higher priority
> filedescriptors in their polls.

Just to share a bit of real-life experience with optimizing poll(2) in
Web Polygraph... I found that the best way is to leave it up to the poll
"user" to decide what FDs are assigned what priority. In many cases, the
user knows better whether a particular FDs is hot or cold. A user may,
of course, call simply rely on the opinion of low-level routines if
needed.

Currently, there are two priorities in Polygraph's implementation of
poll: high (the default) and low. Simplifying a bit, high priority FDs
are polled N-1 times with _zero_ timeout. After that _all_ FDs are
polled with a maximum possible timeout. N is a parameter.

Note that the set of hot FDs is usually relatively small. Polling with
no timeout will bring CPU utilization up, but I do not care about that
because Polygraph runs on dedicated machines and, hence, there is not
reason to "save" CPU cycles.

The above scheme is simple yet proved to be very efficient for
Polygraph, allowing request rate to go from 500/sec to 700/sec on the
same hardware with negligible response time degradation.

$0.02,

Alex.

P.S. If you split all FDs in groups and never poll all of them at once,
     be careful on how you select your timeout. Simply using the timeout
     suggested by the event queue will no longer work. The latter is
     one of the reasons for polling all FDs in Polygraph -- it
     simplifies the logic and eliminates one parameter from the model,
     sort of.
Received on Fri Aug 04 2000 - 13:19:14 MDT