On 4/1/2011 7:27 PM, Sean Kelly wrote:
On Apr 1, 2011, at 2:24 PM, dsimcha wrote:
== Quote from Brad Roberts (bra...@puremagic.com)'s article
I've got an app that regularly runs with hundreds of thousands of
connections (though most of them are mostly idle). I haven't seen it
break 1M yet, but the only thing stopping it is file descriptor limits and
memory. It runs a very standard 1 thread per cpu model. Unfortunatly,
not yet in D.
Later,
Brad
Why/how do you have all these connections open concurrently with only a few
threads? Fibers? A huge asynchronous message queue to deal with new requests
from connections that aren't idle?
A huge asynchronous message queue. State is handled either explicitly or
implicitly via fibers. After reading Brad's statement, I'd be interested in
seeing a comparison of the memory and performance differences of a thread per
socket vs. asynchronous model though (assuming that sockets don't need to
interact, so no need for synchronization).
From the discussions lately I'm thoroughly surprised just how
specialized a field massively concurrent server programming apparently
is. Since it's so far from the type of programming I do my naive
opinion was that it wouldn't take a Real Programmer from another
specialty (though I emphasize Real Programmer, not code monkey) long to
get up to speed.
