"Thomas Tomiczek" <[EMAIL PROTECTED]> wrote: > > I know of NO (!) operating system so far that is made to handle > a high amount of threads running into hundreds.
*Fires up Task Manager. Goes to the Performance tab. Looks at the Totals group box.* Well my Windows XP system here seems to be running with 583 threads right now. Are you sure it can't possible code with hundreds of threads? Seems to be working pretty well to me. :-) It's true that any single process doesn't have that many. The highest score is one of my svchost.exe processes, which has 97 threads running right now. (It's the one hosting netsvcs.) IIRC I think the OS will let you create something like 3000 threads in one process before it actually starts to complain. Also, Sun make boxes with 64 processors don't they? Applying a thread pooling heuristic such as "25 threads per CPU" suggests that you would expect about 1600 threads in the pool... (I know Sun developers who were suprised when I suggested that 200 threads was a lot of threads.) That said, I agree with your conclusions, even if I don't agree with all of your detailed points. :-) > Threads mean that a thread scheduler has to check them > regularly and has to blow it's performance on this. That's not really how the scheduler works. Someone else has already pointed out the runnable/nonrunnable distinction so I won't go into that again. But this is not what the "don't have too many threads" argument is about. Thread switches are the expensive thing. Having a thread there in the first place is relatively cheap, it's switching between them that costs you. This suggests that having 300 threads probably will be relatively expensive. But it might not kill you - it will depend on whether you are in fact CPU bound or not. If you are dealing with 100s of requests a second you might just be OK. For 1000s of requests you're probably dead... It's true that if you can possibly avoid the threads switch that's better. Optimal use of the CPU means 1 thread per CPU... (And never calling any APIs that might block. And always running out of locked-down memory...) >This is why having more runnable threads than you have > CPUs is a *really* bad idea. More runnable threads, yes. But I got the impression that mostly these threads would be blocked most of the time. > I have been involved in a number of high throughput projects > (up to 60.000 requests a minute guaranteed) and have seen > the "a thread per lazy connection" - with lazy connection > defined as a connection not doing anything most of the time, > and I mean processor time) suck up all resources over and > over again. Agreed. Thread switch time seems to be a significant proportion of a millisecond on Windows. (Depends on the hardware of course. On a laptop I've seen it take most of a millisecond. You would expect it to be a little better on a server.) So if you're handling 1000 requests a second, then of you expect context switching time to start to dominate. I think in this case I'd be inclined to contact the vendor to find out if "one thread per channel" is required by their driver archicture, or merely their suggestion. IO completion ports would be a better way of guaranteeing that events can be handled immediately regardless of what is happening on other threads, because you can make sure that there are always enough threads around, without having to have one per connection. (Obviously in theory you could have all threads being busy simultaneously, but at this point your CPU is probably at 100%, at which point having more threads isn't going to improve your response time.) The reason IO completion ports are so much better is that they minimize the number of thread switches whilst maximizing availablilty of the CPU to handle incoming requests. So...consult your vendor. >SIMPLE issue: Every thread has it's own stack. That's if my > memory is correct right now (and .NET threads are assigned > OS threads, don't forget this) 1MB per thread. Thanks for > blowing 300 Mb for nothing so far :-) Nope. As someone else point out, all it reserves is address space. The memory isn't allocated until the stack grows to fill it. -- Ian Griffiths DevelopMentor You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
