On Fri, 1 Apr 2011, Sean Kelly wrote: > On Apr 1, 2011, at 12:59 PM, Jonas Drewsen wrote: > > > On 01/04/11 17.21, Sean Kelly wrote: > >> > >> On Apr 1, 2011, at 7:49 AM, Jonas Drewsen wrote: > >>> > >>> There doesn't have to be a thread for each socket. Actually many servers > >>> have very few threads with many sockets each. 32000 sockets is not > >>> unimaginable for certain server loads e.g. websockets or game servers. > >>> But I know it is not that common. > >> > >> Hopefully not at all common. With that level of concurrency the process > >> will spend more time context switching than executing code. > > > > For services where clients spend most time inactive this works. An example > > could be a server for messenger like clients. Most of the time the clients > > are just connected waiting for messages. As long as nothing is transmitted > > no context switching is done. > > Fair enough. Though I'd still say it's a terrible use of resources, given > available asynchronous socket APIs. And as an aside, I think 32K sockets per > process is not at all surprising. I've seen apps that use orders of > magnitude more than that, though breaking the 64K barrier does get a bit > weird.
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
