the requirements of keep-alive support

[Ian Kallen <ia...@gamespot.com>]

De-lurking here for just a sec....

I just wanted to share my experience with keep alives in a few different
circumstances.  On an SGI Challenge S w/ 128 mb ram, turning on keep
alives always resulted in the pool getting run upto MaxClients with our
request rate of around 50-60 req/sec and before long actually running
slower because of tied up processes, the scoreboard would be just about
wall to wall K's. This would be the case with a keepalivetimeout of 30
seconds or 3 seconds (yes, the IRIX 6.2 patches are up to date).  When I
doubled the installed ram to 256 mb, I could support a much larger process
pool (I upped max clients from 110 to 192, this server also runs a
mod_perl'd daemon separately so I leave room for it in ram :) and turn
keep alives on.  What I find odd is that the number of processes active in
the pool seems really high for the request rate I'm handling, it's much
higher than if I have keepalives off. Granted, responses feel quicker, our
pages are pretty image heavy and they seem to be coming up faster but the
extra performance definitely seems to be paid for with additional ram
requirements.

Incidentally, on a FreeBSD box with 128 megs of ram running a mod_perl
httpd, keepalives are counterproductive unless the request rate is less
than 30 requests per second, that machine's MaxClients sweet spot seems to
be around 115.

I guess I was expecting the required number of processes in the pool to
decrease with keep-alives on but that's not been the case.  In both
instances, the OS is tuned specifically for Web serving and perform
admirably without keep-alives.  I'm curious what other folks with busy
servers are doing for keep-alive support (parameters in httpd.conf).  I'm
assuming it's buggy clients stringing along server processes longer than
they should, so as far as declining keep-alives to misbehaving clients,
this is the setup:

BrowserMatch Java1.0 force-response-1.0
BrowserMatch JDK/1.0 force-response-1.0
BrowserMatch "MSIE 4\.0b2;" downgrade-1.0 force-response-1.0
BrowserMatch "MSIE 3\.01;" downgrade-1.0 force-response-1.0

...if there's a better one, I'd be happy to here about it.  There's
nothing in the tuning docs about optimizing use of keep-alives, just
the old stuff about FIN_WAIT_2's and buggy clients.  If folks respond
to me privately, I'll be glad to write up something for the docs.  If
folks want to respond publicly, I'll just go back over here and re-assume 
lurk mode.

BTW, all of our httpd's are 1.3b6 :)

--
Ian Kallen						ian@gamespot.com	
	Director of Technology and Web Administration
		GameSpot Incorporated
http://www.gamespot.com/		http://www.videogames.com/

Re: the requirements of keep-alive support

[Boaz Yeger <by...@ee.ucr.edu>]

Hello,

Before you all flame me that my question is a CGI question, etc, I am writing
it to you (the apache developers) since I think that the problem I am having
is with the Apache web server 1.2.6.

I am running the 1.2.6 on a RedHat 4.2 i386, and I send a form to a CGI
script.  The script, than does double fork, change the process group number of
the child, and execute a job.  This job can run from 5 seconds to 7 hours.
The problem I am having is that if the job is not done in 10 seconds, it just
die.

Here is what I am doing:

     unless($pid = fork) {
       setpgrp(0, 0);
       unless (fork) {
	 setpgrp(0, 0);
	 close(STDIN);
	 close(STDOUT);
	 close(STDERR);
	 exec ("my program");
	 exit(0);
       }
       exit(0);
     }
     waitpid($pid,0);

Doing so, I hoped will make sure that Apache can find that spawned child and
kill it.

When I run the script dry (i.e. invoke it from the command line and not via
the web server), I have no problems - The job never die.  However, once I
invoke it over the web...

I tried to trap all possible signals (SIGTERM, SIGPIPE, SIGHUP), but no luck.
>From looking at mod_cgi.c it seems like it sending a kill signal.
Nevertheless, from looking at http_main.c I tend to believe that it need to
record a kill signal, but there is no record of it in any of my logs.

So...

 1.  Is the death after 10 seconds is a known thing in Apace 1.2.6
 2.  If so, what can I do to resolve it

Thanks in advance for you time and your help,

Boaz
-- 
Boaz Yeger		 | VOICE:  909.787.2986	
Network Systems Manager  | FAX:    909.787.3188 
College of Engineering   | E-Mail: systems@ee.ucr.edu
University of California | E-Mail: byeger@ee.ucr.edu
Riverside, CA 92521-0304 | WWW:    http://www.ee.ucr.edu/~byeger 

Re: the requirements of keep-alive support

[Ian Kallen <ia...@gamespot.com>]

Thanks Dean!

On Mon, 25 May 1998, Dean Gaudet wrote:
:> I guess I was expecting the required number of processes in the pool to
:> decrease with keep-alives on but that's not been the case.
:
:No it's definately not the case.  It's the opposite.  When keepalives are
:turned on you require usually four processes per client, and they stick

Wow, that's news to me.  If it's in the docs, I scanned right past it...

:around doing nothing until the next request or timeout.  I'm surprised you
:see the same behaviour with a timeout of 3 seconds though... you didn't
:change SCOREBOARD_MAINTENANCE_INTERVAL did you?

Nope. 

:Do you know if timeouts are broken?  Try this:

KeepAliveTimeout definitely does _not_ seem broken, at least on my test
systems.   The httpd's are all in a hung state when I turn them on and the
pool is maxed out on the FreeBSD machine I have in production, even if
I set the KeepAliveTimeout to 1 so I don't know how I feel about my
observations of KeepAliveTimeout on the machine when it's loaded up... I'd
need to set up a test bed to load up and then compare the behaviours for
further data, which isn't going to happen anytime soon.  I guess I'm just
trying to get a handle on tuning requirements.  And hardware hardware too!
These SGI Challenge S' max out at 256 mb ram and FreeBSD won't support
more than 256 mb without any very serious hocus pocus that, it appears,
only a few people on the planet seem to understand (their initials are DG
and JKH and God love them :)

I would imagine that a 1 second keepalivetimeout and keepalive off would
have similar performance characteristics but that's far from the case, I
still get a scoreboard jammed up with K's and a comatose server.

Right now, my sweet spot for the IRIX machine's KeepAliveTimeout seems to
be about 4 seconds. Any longer, my pool is jammed up.  Any less, I imagine
the benefit declines (clients have to open new connections anyway, cause
they didn't ask for anything soon enough and therefore may as well be
doing separate requests anyway). Though I'm currently thinking that
for high latency clients, ya just have to say fuck 'em and force them to
emit separate connect requests lest the pool get tied up waiting on them.  

--
Ian Kallen						ian@gamespot.com	
	Director of Technology and Web Administration
		GameSpot Incorporated
http://www.gamespot.com/		http://www.videogames.com/

Re: the requirements of keep-alive support

[Dean Gaudet <dg...@arctic.org>]

On Mon, 25 May 1998, Ian Kallen wrote:

> I guess I was expecting the required number of processes in the pool to
> decrease with keep-alives on but that's not been the case.

No it's definately not the case.  It's the opposite.  When keepalives are
turned on you require usually four processes per client, and they stick
around doing nothing until the next request or timeout.  I'm surprised you
see the same behaviour with a timeout of 3 seconds though... you didn't
change SCOREBOARD_MAINTENANCE_INTERVAL did you?

Do you know if timeouts are broken?  Try this:

telnet myserver 80
GET / HTTP/1.0
Connection: keep-alive

Don't forget the extra CRLF there at the end... and then wait after the
response, and time it to see that it closes after your keepalive timeout.

Dean