> Why can't you imagine it? Current Linux-2.1.x can create 30,000 TCP
> sockets in just under 10 seconds (actually, create _and_ destroy
> them). But you are right the fd table size limit is another issue.
Keeping them simultaneously open? Opening, then closing socket shouldn't
be that much of a problem, if the other end of TCP connection behaves
properly, but as I understand it, those sockets are kept open and at least
monitored for input in poll().
> But once the fd limit is taken care of, poll() scalability in such
> situations is not all that hard and can probably be done with the
> current poll() implementation quite easily.
>
> On a seperate related note, poll() scalability is one of the important
> bottlenecks to fix for a high end web server once the bulk of TCP
> scales well (ours in 2.1.x certainly does).
As an FTP/HTTP server author I'm very interested in that -- I use model
with single never-block-on-anything process that does poll() or select(),
and fd passing to other processes that actually serve requests. While I
have succeeded in keeping main process small, so paging won't cause any
grief, small number of fds per process is a serious limitation (I keep all
sockets opened in main process, so it can reuse other processes without
connection binding for a lifetime), and possibly the high number of
context switches can cause some performance loss in this model, however in
the case of relatively fast context switch between processes and possibly
increased fd per process number poll() efficiency can become significant.
-- Alex
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu