fork() vs pthread

[sedj]

Hi,

I have a server listening on a TCP socket. When a client connects, I fork a process, and that process takes between 100ms - 1000ms. Should I bother with using threading (pthread), or will fork be *in effect* just as quick ?Running on a dual Xeon 2.8GHz linux machine.

Cheers

Ben

 

[Salem]

First thing, is the system keeping up at the moment, or are you after better performance?
If it's keeping up and you've got nothing better to do with the CPU time then I'd leave it alone.

Do you limit the number of connections which can be made? The number of processes which can be fork'ed in a system is usually pretty low. If you don't take care, it becomes an easy DoS for someone.

Threads are lighter on the system than forked processes, but greater care is needed in using them.
For example, a small memory leak in a forked process would not matter given it's short-lived nature, since the OS reclaims all memory when the process exits. In a threaded environment, such leaks would be cumulative.
Also, threads share the same memory space, so errant code which would otherwise crash the program may find some usable memory and continue (at the expense of something else later on).
Like processes, threads are also limited in number.

A third option would be to dispense with processes and threads altogether and use the magic of the select() call to monitor multiple connections at the same time, and inform you when there is something worth doing.

--

 

[sedj]

Hi Salem,

Thanks for the reply.
When the app is running at near-expected levels of load (around 10 requests per second), the CPU is not even stessed out, it runs at max 5% load on the box, and this is a dedicated server, so thats no problem.

I don't limit the number of connections at the moment, because we know what the load will be (maximum load will be 10 requests per seconds), and if load exceeds this, and app cannot deal with it, we will add another box and loadbalance the two.

Basically my question is, does threading significantly improve the allocation of a recv|()'d socket connection, or is fork()'ing the process acceptable. The app is creating images on request & milliseconds counts - even 20-30 mill makes a difference, and if threading vs forking will give that, then I'm willing to make the change, as it were. On the other hand, forking seems easier !

Cheers,

Ben



--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk

 

[Salem]

> does threading significantly improve the allocation of a recv|()'d socket connection,
> or is fork()'ing the process acceptable.
From a strictly functional point of view, I can't think of anything which would make a difference here.

Performance wise, threading should be better (ie quicker), but its harder to quantify by how much.

If your forked processes are short-lived, then the cost of a fork()/execl() will dominate. A threaded solution would be worth a shot.

But if your processes use say 1 second of CPU time, then the few milliseconds it takes to fork()/execl() will be down in the noise as far as the performance of the whole system is concerned.

--

 

[sedj]

Thanks for the advice Salem.

--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk

 

[marsd]

I'm going to disagree with a couple of points here.

1. select() requires some serious rethinking of code
that doesn't use it. That may not be a problem.

"A third option would be to dispense with processes and threads altogether and use the magic of the select() call to monitor multiple connections at the same time, and inform you when there is something worth doing."

2. Just for the sake of argument: where are all these
socket descriptors and 'connections' coming from and where are they in the process table if they haven't been forked off the parent in the case of constrained multitasking?
I don't understand the above comment.

Personally I'd use pthreads and just try to be a good programmer and clean up any dynamically alloc'd
resources and catch errors in the threads.