From: Chuck Murcko <chuck@telebase.com>
Message-Id: <199605022113.RAA06773@telebase.com.>
Subject: Re: mod_status again
To: new-httpd@hyperreal.com
Date: Thu, 2 May 1996 17:13:02 -0400 (EDT)
In-Reply-To: <ML-2.3.831070689.2767.rasmus@rathaus> from
 "rasmus@madhaus.utcs.utoronto.ca" at May 2, 96 04:58:09 pm
Content-Type: text
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

rasmus@madhaus.utcs.utoronto.ca liltingly intones:
> 
> I am using the source patch that you posted to the list (unless you posted 
> a second patch that I haven't seen yet).
> 
That was the only patch to the list.

> > The 1st number of the Accesses and the B1 kByte counts
> > refer to the *last* completed connection, and do account for keepalives.
> 
> Hmm..  I have Keep-Alives on and re-loading the status page over and over
> again never brings that number above 1.  
> 
Hmm. Apparently the second scoreboard update in http_main.c is not tabulating
keepalives, then. But the status page is only a single connection, and
Netscape 2.x, at least, seems to prefer opening a second or third connection
to using a keepalive, at least at the default connection setting of 4.

> > For no keepalives, the number will be 1. For keepalives the number is > 1.
> > The second Access number is total requests served by this child. Before
> > the http_main.c change, both numbers read total requests.
> 
> No, before the change the first number showed the total number of requests
> served by the current child process while the second number showed the
> total number of requests served by the scoreboard slot.  If you had
> MaxRequestsPerChild set to 0, then these two numbers were the same.
> 
OK, then. That's how I ran them, and that's what they showed. I see 5-10
as a count in the first column on a pretty large number of connections
here, and > 1 on about 7% of active connects.

> I don't think the number of requests for the last connection tells
> me very much.  I'd rather see how many requests this particular process
> has served so I can compare that to the amount of memory it is taking up
> and thereby adjust my MaxRequestsPerChild setting to keep memory leaking
> under control.
> 
You can do this by reverting to the original http_main.c or reversing
that part of the patch. The scoreboard slot total *is* the total for the
child, though, since that count is cleared when a server dies.

chuck
Chuck Murcko	N2K Inc.	Wayne PA	chuck@telebase.com
And now, on a lighter note:
The chicken that clucks the loudest is the one most likely to show up
at the steam fitters' picnic.