> I spent the day implementing a poll()-based version of
> the server and making sure it was correct. To be efficient,
> only the file descriptors that are in use are in the
> pollfd array. However, this isn't a great savings for
> me, since about 80% of the descriptors turn out to be
> "active" in this server. I tested it using 4000 descriptors.
Then you're probably wasting more time putting things into and out of the
array than the cost to just leave the array as it is.
> This new implementation using poll() seemed to actually
> have higher overhead than the select()-based version. On
> some level, this makes sense - select uses 2 bits per
> descriptor for the read/write sets, and since they're
> in/out parameters, that's 4 bits each. Poll uses one int
> plus two shorts, for a total of 64 bits per descriptor.
You're probably doing something wrong. For example, you should be building
the 'poll' array just once. You don't need to rebuild the entire array each
time you call 'poll'.
> Even so, that wouldn't explain the performance I'm getting
> with either version. Are there any tunable parameters
> relating to the networking code? Hash table sizes,
> enabling/disabling delayed acks, etc? The same program on
> a different operating system gets about 50% higher performance.
> I'm sure I'm overlooking something small. Any suggestions
> would be appreciated.
Odds are there's something bad about your program that hurts it more on
Linux than other platforms.
It may help to use multiple threads and have one thread that polls on the
busiest file descriptors and one that polls on the less busy ones. This way,
your most frequent calls to poll will be for a smaller number of
descriptors, minimizing the number of wait queues the kernel has to put you
on and pop you off of.
It may also help to use one thread per 1,000 file descriptors. This way,
each call to poll requires the kernel to process at most 1,000 file
descriptors.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:27 EST