Andy, I know of NO (!) operating system so far that is made to handle a high amount of threads running into hundreds. Threads mean that a thread scheduler has to check them regularly and has to blow it's performance on this.
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. 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 :-) More inline... Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -----Original Message----- From: Mcmullan, Andy (Andrew) [mailto:[EMAIL PROTECTED]] Sent: Montag, 1. Juli 2002 13:45 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Massive Use of Threads Issue Thomas, I'm surprised that you can provide such an apparently definitive answer without knowing more about the environment. *** Some have this knowledge. That's on the same level as "don't pour water over a running computer" - you don't need to know too much about the environment to come up with common sense like this. For a start, the hardware vendor is likely supplying software libraries used to interface with the boards. It may be that the design of these libraries makes a thread-pool approach difficult. For example, telephony applications generally wait on events from the board (e.g. events signalling incoming telephone calls) - how are these events exposed? Async calls from library-created threads? Or does the application thread need to call a blocking library call to wait? Is thread affinity an issue? *** "It may be.... makes a thread-pool design approach difficult" - then get it done nethertheless :-) Thread affinity, for example, is only an issue if you make it one. Massive throughput development is not easy. Never. Seems like programming is needed now. Although developers are generally educated that "many threads is bad", it's not necessarily true in all cases. With telephony resources you have distinct 'ports' (or 'timeslots') that logically fit with threading in such a way that one-thread-per-resource can make a lot of sense. Node that peak throughput is not usually the main requirement in a telephony system. *** Last time I was making a system for a telephony application it had to handle (guaranteed) 60.000 events per minute, with a max of 90.000. The design had stages computers with the front end systems handling the communication with the phone system. Don't say that telephony applications don't need high throughput. *** Also, your timeslots are NOT mapped to threads natively. Windows is NOT made to handle hundreds of threads. It is bad design, and it I countering the way the OS is programmed. *Responsiveness* is the key. No point having 30 callers being handled super-efficiently if that means 200 other callers are being kept 'on-hold'. Better to waste a bit of CPU context-switching and handle all 230 callers simultaneously. *** NO. Sorry, no way. You misunderstand a lot here. Having a thread-pool of lets say 60 threads on a dual processor does not mean that 230 people will wait. They will wait until a thread is free - and threads become free VERY fast when programmed effectively. WAY faster than having 300 threads all "unlocking" at the same time and fighting for processor time in a scheduler not made to handle them like this. They will propably not even recognize the delay, unless you run out of processor time "big time", and then 300 threads are just making it way worse. *** IIS can handle thousands of requests a second - but only because it uses the pool approach. So my advice to David would be to not get hung up on the number of threads. 300 threads is not by itself going to cause you any fundamental technical problems. My first thought on reading the message was "Are you really going *** Well, I suggest you learn something about the way Windows allocates - memory. 300 Threads will cause a significant bloat of his application, numerous processor state reloads and bog down his application. Thomas You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
