Couldn't be farther form the truth. Try to launch 20.000 threads and let them all sleep. You'll see 100% cpu-usage. No way it's "just as bad".
on my 20.000 core system it runs perfectly fine.
1 thread per client scales just as bad as one thread for the whole app
Obviously there's a finite limit on how many connections a single thread can handle, either due to consumption of available resources or limitations of the underlying network API. No one said you have to use a single thread to manage connections, just that there's no need to use a thread
per connection. I've seen designs that manage connections in groups (where a group is a set number of connections, like 64, 128, 1024, or whatever), using two threads per group - one for receiving and one for sending.
The point is that one thread per connection does not scale well at all, but multiple connections per thread does.
your guys are missing the point I'm making.
where did I preach that 1 thread per connection is the way to go or any good.
if you have or rather need to have 20.000 concurrent connections with need you apperently need to send some data I doubt there is any affordable processor who has one core that can handle all that. So esp in terms of scaling. 20.000 connections on 20.000 threads is just as bad as 20.000 connections in 1 thread.
offcourse other ratios are much better, as jeff and riven/yourserf indicate. these ratio's iether way you end up with one or more thread thus you need to take into account multi threading and thread savety. Some ppl seem to proclaim that oe 1 thread per connection sux (which it does wenn you expect many connections) and then make the crazy conclusion that everything needs to be in one thread and that they don't need to learn to write multithreaded code.
appearandly it doesn't come as obvious to some.
and The point is that one thread per connection does not scale well at all, but niether does sticking to one thread.
