What is best, a Single-threaded or a multi-threaded server?

Question

I have to create a simple client<->server communication to transfer files using C language (Linux).

The server accept connections on the 10000 port, I don't know if is better to create a new thread each request or create a fixed numbers of threads and use asynchronous technique.

CASE A:

client --> server --> (new thread) --> process the request

CASE B:

SERVER --> create thread 1 - thread 2 - thread 3

then

client1 --> server --> thread 1
client2 --> server --> thread 2
client3 --> server --> thread 3
client4 --> server --> thread 1
client5 --> server --> thread 2
client6 --> server --> thread 3

In this case thread 1 could process many client's requests

My considerations:

CASE 1: Is faster but waste a lot of memory

CASE 2: Is slower but use a low memory

Am I wrong?

Answer 1

If you consider checking architecture of widely used http servers ( nginx, lighttpd, apache ) you'll notice, that ones using fixed thread count ( so called "worker threads", their amount should depend on processsor count on server ) are a lot faster then one using large thread pool. However, there are very important moments:

1. "Worker thread" implementation should not be as straightforward as it is tempting, or there will be no real performance gain. Each thread should implement each one pseudo concurrency using state machine, processing multiple requests at time. No blocking operations can be allowed here - for example, the time in thread that is wated to wait for I/O from hard drive to get file contents can be used to parse request for next client. That is pretty difficult code to write, though.

2. Thread-based solution ( with re-usable thread pool, as thread creation IS heavyweight operation ) is optimal when considering performance vs coding time vs code support. If your server is not supposed to handle thousands of requests per second, you'll get ability to code in pretty natural blocking style without risking to fail in performance completely.

3. As you can notice, "worker thread" solutions itself service only statical data, they proxy dynamic script execution to some other programs. As far as I know ( may be wrong ), that is due to complexities with non-blocking processing of request with some unknown dynamic stuff executed in their context. That should not be an issue in your case, anyway, as you speak about simple file transfer.

The reason why limited thread solution is faster on heavy-load systems - thread http://en.wikipedia.org/wiki/Context_switch is pretty costful operation, as it requires saving data from registers and loading new one, as long as some other thread-local data. If you have too many threads compared to process count ( like 1000x more ), a lot of time in your application will be wasted simply switching between threads.

So, short answer to your question is: "No, it has nothing to do with memory usage, choice is all about type of data served, planned request/second count and ability to spend a lot of time on coding".