Hi,
On Thu, 9 Mar 2000 22:35:26 -0500 (EST), Matthew J Zito
<mjz207@is9.nyu.edu> said:
> So, assuming that we raise the file descriptors to an appropriate number,
> we could theoretically hold 8000 sockets in 500 megs of memory? At what
> point does poll() start getting dicey?
It depends entirely on the load:
1) If you have 8000 open fds but the data
is only coming in on one at a time, then you are asking the kernel to
check 8000 sockets every time one piece of data has to be dealt with.
That is inefficient.
2) If you call poll on 8000 fds and find several hundred or more of them
active, then you've just obtained a lot of information about pending
work with just a single syscall. That is efficient.
So it starts getting dicey based on the incoming workload.
Unfortunately, internet servers see a lot more of case 1) than of case
2), because slow clients and packet loss lead to long stalls on a lot of
your connections.
The 2.2 supports a queued-signal mechanism which tells you exactly which
sockets have data pending, and when. We've polished that mechanism
significantly for 2.3. Using that sort of API lets you avoid the
performance penalty of checking for idle sockets.
--Stephen
-
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 : Wed Mar 15 2000 - 21:00:18 EST