[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Single-threading servers and select()
- From: David Burgess <dburgess@...>
- Date: Sun, 23 Jan 2005 11:35:53 +1000
Remember that there are selects() friends devpoll/kqueue/poll (and others?).
In the real world I have found the select() overhead to be insignificant.
As someone (Mike I think) pointed out, if you are processing 1000's of
concurrent connections the socket APIs are probably not what you want.
I have found the critical issues(in my world) to be:
- connection rates (how fast can you accept a connection).
- bandwidth.
In the server applications I have been involved with, select() (or
something like it)
has not been an issue. Managing bandwidth is an issue. Non-blocking / async IO
applications are simpler to code and debug and hence manage bandwidth.
High performance commercial web servers such as zeus are minimally threaded
and use non-blocking IO. The argument about non-blocking/single threaded versus
blocking/multithreaded is settled by Web server benchmarks.
Non-blocking wins the
benchmarks. Non-blocking scales.
DB