httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brandon Long <>
Subject Re: non-forking again
Date Thu, 16 Mar 1995 07:35:47 GMT
Last time, Rob McCool uttered the following other thing:
>  * *) You've got to be quite a bit more careful with malloc() and
>  *    friends --- memory leaks don't matter in a forking server, since
>  *    the process is going to die pretty quickly anyway, but in a
>  *    non-forking server they add up fast.  (Note that there are some
>  *    portions of the existing code base which use strdup() uncomfortably
>  *    freely).
> If I remember the NCSA code right, it leaks memory and file
> descriptors like a sieve. strdup() is used in a couple of places,
> though most of the code opts for the stack-based approach of memory
> allocation. At the time, doing all of that made sense...

Well, 1.4 should do this much better (its coming, maybe next week),
and does use a multi-child approach.  I think we've got all of the 
memory leaks, but I'd be willing to bet we missed one or two . . .
>  * A final note --- simple implementations of the NetSite-type "mob
>  * process" mechanism (a bunch of processes all doing accepts on the
>  * same socket) are vulnerable to the effect I discovered with my
>  * MaxProcs experiment, namely that long requests (such as CGI hits
>  * and server-side includes files with <!--#exec --> directives) tend
>  * to starve out short ones, with deleterious effects on both latency
>  * and throughput.  (I think Rob McCool has also seen this effect when
>  * he was evaluating alternate NetSite designs --- Rob, are you out
>  * there?)
> Yes. For normal files, this is not a problem mostly because socket
> buffers if large enough can allow you to turn over processes faster
> than you disconnect clients (along with having SO_LINGER turned off). 
> For CGI, a server could require more processes if these CGI programs
> did a lot of stuff (especially if they were long-running CGI programs
> implemented through shell scripts which can't detect a client
> disconnect). 
> At some point, you should want to assert that N is as high as the
> number of processes can get. Allowing uncontrolled forking is a bad
> idea. The question becomes when do you spawn those N children, one at
> a time, as they're needed then keep them around, or do the Netsite 1.0
> approach and spawn them all to begin with in order to avoid the shared
> memory requirements associated with coordinating growth and reduction
> of a process set.

1.4 gets around this (sorta) by having a maximum number, and if they are
all taken, it reverts to a 1.3 style (fork and die).  This means that
under the heaviest load, its still forking :(, but the cgi problem can
get really bad.  nph scripts (or the new apache stuff) should work
around this, by taking the server out of the cgi loop.  A certain
archie cgi script on hoohoo.ncsa showed us how bad cgi can be (most of
them never finish, I think)
>  * You could get around this by having a large number of processes in
>  * the mob, at a nontrivial cost in swap space, or by arranging for
>  * "long" transactions to be shelved if too many potentially short
>  * ones are queued up behind, which is doable, but very very hairy.
>  */

One suggestion we had, was to have a forked child stay around for some
length of time, and if not in use for that time, die.  Kinda a self
balancing act.  This didn't make 1.4, since I wasn't sure how to do it

One other item of note: we don't have multiple children waiting on
accept, though its been batted around.  I had no idea what it would
do.  Currently, we use file descriptor passing to pass the accepted 
socket from the 'root' process to a 'child.'  Unfortunately, some 
systems don't implement this.  To those systems, 1.4 is going to be
a slightly improved 1.3.  One such system is Linux.

NCSA HTTPD Server Development
Following in Rob's shoes (who owes who beer?)

 Brandon Long   (N9WUC)     "I think, therefore, I am confused." -- RAW
 Computer Engineering   	Run Linux	It's that Easy. 
 University of Illinois
		Don't worry, these aren't even my views.

View raw message