Re: Single-threading servers and select()

[skaller <skaller@...>]

On Sun, 2005-01-23 at 11:52, duck wrote:
> Recently, it was suggested that select()-driven TCP servers could never 
> scale to many 1000s of connections because of the linear cost of searching 
> the select array each time a non-zero number of connections had some data
> handy.
> 
> In the real world, is this really an intractable problem? 

Yes and no :)

In the real world, Apache solves the problem
by allowing a certain number of connections which it
can handle .. and just refuses any more. There are
other reasons (denial of service attacks for example)
for doing this.

Also, a general web server has a lot more work
to do than just connect, such as serving pages,
perhaps by calculating stuff with PHP or CGI,
and is unlikely the TCP/IP load would be the
real problem. (The database is the more likely
bottleneck)

But that's for a *general purpose server*.

The situation is different for a specialist
server. For example a static page only server,
such as you might use for an online Wikipoedia,
or, more interesting from a MONEY point of view,
an e-commerce system (such as eBay or Amazon
or PayPal).

Or -- and this is a *real* example -- the online
game Utopia which is a massively multiplayer game
with 50,000 people playing (that is a *real* figure).

In Utopia, you play a couple of turns every day,
and stay online for perhap 1/2 an hour each time,
and whilst online you do a number of page fetches,
so the number of simultaneous connections is
usually managable.

There is one exception -- when the game goes live.
In that case everyone is eager to play, since the first
few minutes are critical .. and the server gets 
swamped.

In fact, the players get frustrated by 'connection
refused' and hit 'reload' button on their browser
again and again.. so the players actually create
a 'denial of service attack' by swamping the server
with a continuous stream of connection requests.

Amazon might solve this problem by buying more
servers .. but Utopia is run by a small company,
and its free to play .. they can't afford to buy
more servers.

I'm sure you can think of applications that need
a lot of connections which you'd like to run
on a small machine .. a chat client might be
another one. (Lots of chat users remain
connected to their favour channel permanently,
even when not monitoring it, so the chat
traffic is low, but the number of connections
can be very large).

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net