httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Kallen <...@gamespot.com>
Subject Re: the requirements of keep-alive support
Date Mon, 25 May 1998 19:49:27 GMT

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/





Mime
View raw message