"Ben Kloosterman" <[EMAIL PROTECTED]> wrote: > I was going to disagree with Ian , > > While threads are expensive when traffic is going to block on disk > or network traffic I always think Threads are a good solution. You > can minimise the overhead by creating your own threadpool .
It wasn't the use of multiple threads per se. It was the use of one thread per requests - this is a massive waste of resources. You would be far better off using the Socket class from the framework class libraries, and using its asynchronous facilities, i.e. call BeginSend to send data. Using this approach you can send off any number of concurrent requests from a single thread. (You can get notifications when transmits and receives complete and these happen on thread pool threads, so multiple threads are invovled. But you never create them explicitly.) The only reason for using threads here is to avoid having the CPU sit around and wait for stuff to happen at the network level when it could be doing other useful work. With async Socket programming you can do this without needing multiple threads. Given this ability, the only possible advantage of using multiple threads would be to exploit multiple processors - that way you might theoretically be able to do twice as much. But in practice two issues would almost certainly mean that you wouldn't do this in practice: (1) contention within the kernel - if both processors are trying to use the same networking stack and the same network card to send or receive data, they will eventually end up both trying to acquire the same spinlocks at the same time. (2) more importantly, you will almost always be limited by the speed of the network, not how fast you can stuff data into it. (For a test rig. Of course this is not true in general, as otherwise nobody would ever use load balanced web farms...) > In this case I may be wrong as the initialization cost of your class may > be quite high . It may be more efficient to intialize it once and send the > 50 messages in a loop. I suspect the class initialization cost will be low compared to the cost of creating a thread. > Have you run a profiler on the program ? Generally if your CPU is > 100% than threads will not help ( they will make it worse) - If you > are not reaching a high cpu level then threads will help a LOT. But using asynchronous socket calls on a single thread will help at least as much on a single CPU system. You can queue up just as much outbound network traffic, and you won't be paying the overhead of getting the OS scheduler to do the work for you. -- 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.
