views:

250

answers:

1

I am trying to optimize multiple connections per time to a TCP socket server.

Is it considered good practice, or even rational to initiate a new thread in the listening server every time I receive a connection request?

At what time should I begin to worry about a server based on this infrastructure? What is the maximum no of background threads I can work, until it doesn't make any sense anymore?

Platform is C#, framework is Mono, target OS is CentOS, RAM is 2.4G, server is on the clouds, and I'm expecting about 200 connection requests per second.

+6  A: 

No, you shouldn't have one thread per connection. Instead, you should be using the asynchronous methods (BeginAccept/EndAccept, BeginSend/EndSend, etc). These will make much more efficient use of system resources.

In particular, every thread you create adds overhead in terms of context switches, stack space, cache misses and so on. Linux is better at managing this stuff than Windows, for example, but that shouldn't be an excuse to give you free reign to create as many threads as you like ;)

Dean Harding
@codeka What about process per connection. when client connects to server. server creates different process and redirects client to it?
Sergey Mirvoda
Well, it's technically the same with one process per connection. That's why Apache (for example) now-a-days use a pool of "worker processes" to handle simultaneous requests, rather than one process per connection.
Dean Harding
+1 for mentioning thread pools... might be a good approach for OP to implement
Sam Post