On Tue, 2009-06-23 20:52:30 -0400, Terry Riegel wrote:
On Jun 23, 2009, at 11:01 AM, Ludolf Holzheid <[email protected]
wrote:
On Tue, 2009-06-23 10:33:14 -0400, Terry Riegel wrote:
If I did it the way you are suggesting then 5 concurrent users would fire up 30 processes. On my system starting the daemon starts 6 processes, and if I start it up again I get another 6 processes.
Is this still true with 'foreground = yes'?
Yes.
You are right. On detaching to the background, there is an additional fork(), but the parent dies early. So the number of persistent processes is the same.
For reducing the number of processes, you might also try to configure stunnel with --disable-libwrap.
I can try that wasn't aware of it as a configuration option
There is also a '--with-threads=pthread' option that may help to lower the number of processes.
However, on modern operating systems, fork()ing is not as expensive as it looks like. In most cases, the text segment is shared between the two processes and the pages on data/BSS segments are not copied until changed ('copy-on-write'). I don't know if the usage of OS resources is larger for the multi-threaded or the multi-tasked approach.
Ludolf
P.S.: Please reply to the list, so the community is able to follow all of the thread.
There is also a '--with-threads=pthread' option that may help to lower the number of processes.
However, on modern operating systems, fork()ing is not as expensive as it looks like. In most cases, the text segment is shared between the two processes and the pages on data/BSS segments are not copied until changed ('copy-on-write'). I don't know if the usage of OS resources is larger for the multi-threaded or the multi-tasked approach.
Perhaps I am confused, but are you saying that when firing up stunnel twice with two separate configuration files they are sharing resources?
Sorry about not posting to list earlier.
Terry
On Wed, 2009-06-24 07:57:30 -0400, Terry Riegel wrote:
However, on modern operating systems, fork()ing is not as expensive as it looks like. In most cases, the text segment is shared between the two processes and the pages on data/BSS segments are not copied until changed ('copy-on-write'). I don't know if the usage of OS resources is larger for the multi-threaded or the multi-tasked approach.
Perhaps I am confused, but are you saying that when firing up stunnel twice with two separate configuration files they are sharing resources?
If you are starting several instances of stunnel, I don't expect them to share resources (other than the text segments of the shared objects).
If, in contrast, a running stunnel process fork()s into two (or, as in your case, 6 processes), these new processes will share resources.
What I wanted to say is, you can't add the resource usage of the single processes in a process tree to get the overall resource usage. A daemon fork()ing into two or more single processes seems much more expensive (w.r.t. resource usage) than it looks like.
Ludolf
On Wed, Jun 24, 2009 at 02:37:13PM +0200, Ludolf Holzheid wrote:
On Wed, 2009-06-24 07:57:30 -0400, Terry Riegel wrote:
However, on modern operating systems, fork()ing is not as expensive as it looks like. In most cases, the text segment is shared between the two processes and the pages on data/BSS segments are not copied until changed ('copy-on-write'). I don't know if the usage of OS resources is larger for the multi-threaded or the multi-tasked approach.
Perhaps I am confused, but are you saying that when firing up stunnel twice with two separate configuration files they are sharing resources?
If you are starting several instances of stunnel, I don't expect them to share resources (other than the text segments of the shared objects).
If, in contrast, a running stunnel process fork()s into two (or, as in your case, 6 processes), these new processes will share resources.
What I wanted to say is, you can't add the resource usage of the single processes in a process tree to get the overall resource usage. A daemon fork()ing into two or more single processes seems much more expensive (w.r.t. resource usage) than it looks like.
^^^^^^^^^^^^^^^^^^ ...was that supposed to be "...than it actually is"? :)
G'luck, Peter
On Wed, 2009-06-24 15:41:26 +0300, Peter Pentchev wrote:
On Wed, Jun 24, 2009 at 02:37:13PM +0200, Ludolf Holzheid wrote:
A daemon fork()ing into two or more single processes seems much more expensive (w.r.t. resource usage) than it looks like.
^^^^^^^^^^^^^^^^^^...was that supposed to be "...than it actually is"? :)
Yes, of course.
Or "... is much less expensive than it looks like".
I didn't really decide ...
Ludolf
On Jun 24, 2009, at 8:37 AM, Ludolf Holzheid wrote:
On Wed, 2009-06-24 07:57:30 -0400, Terry Riegel wrote:
However, on modern operating systems, fork()ing is not as expensive as it looks like. In most cases, the text segment is shared between the two processes and the pages on data/BSS segments are not copied until changed ('copy-on-write'). I don't know if the usage of OS resources is larger for the multi-threaded or the multi-tasked approach.
Perhaps I am confused, but are you saying that when firing up stunnel twice with two separate configuration files they are sharing resources?
If you are starting several instances of stunnel, I don't expect them to share resources (other than the text segments of the shared objects).
If, in contrast, a running stunnel process fork()s into two (or, as in your case, 6 processes), these new processes will share resources.
What I wanted to say is, you can't add the resource usage of the single processes in a process tree to get the overall resource usage. A daemon fork()ing into two or more single processes seems much more expensive (w.r.t. resource usage) than it looks like.
Thanks for the clarification. Thats what I thought. So it sounds like to use stunnel for my needs I would have to start and stop the process for every cgi connection. It seems like it would be beneficial to have it dynamically add/remove hosts during runtime.
Thanks for the information. I appreciate your answers.
Terry Riegel [email protected] wrote:
Thanks for the clarification. Thats what I thought. So it sounds like to use stunnel for my needs I would have to start and stop the process for every cgi connection. It seems like it would be beneficial to have it dynamically add/remove hosts during runtime.
Configuration file reload is on my TODO list: http://stunnel.mirt.net/?page=todo_sdf All it needs is a week of my time... Would you like to sponsor this feature? Many people would appreciate it.
Mike
-
Ludolf Holzheid -
Michal Trojnara -
Peter Pentchev -
Terry Riegel