Received: by taz.hyperreal.com (8.6.12/8.6.5) id NAA03662; Thu, 2 May 1996 13:19:08 -0700 Received: from shado.jaguNET.com by taz.hyperreal.com (8.6.12/8.6.5) with ESMTP id NAA03655; Thu, 2 May 1996 13:19:06 -0700 Received: (from jim@localhost) by shado.jaguNET.com (8.7.5/jag-2.2) id QAA29036 for new-httpd@hyperreal.com; Thu, 2 May 1996 16:19:04 -0400 (EDT) From: Jim Jagielski Message-Id: <199605022019.QAA29036@shado.jaguNET.com> Subject: Re: mod_status again To: new-httpd@hyperreal.com Date: Thu, 2 May 1996 16:19:04 -0400 (EDT) In-Reply-To: <199605021951.PAA03330@telebase.com.> from "Chuck Murcko" at May 2, 96 03:51:10 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-new-httpd@apache.org Precedence: bulk Reply-To: new-httpd@hyperreal.com Chuck Murcko wrote: > > rasmus@madhaus.utcs.utoronto.ca liltingly intones: > > > > The access counting has changed. It states: > > > > "Number of accesses this connection / number of accesses total by child" > > > > I don't understand what the first number means. This connection? ie. a > > > You may want to use the source patch that hit the mailing list after your > reply. It parses the form data set correctly, allowing multiple options > in a request. The 1st number of the Accesses and the B1 kByte counts > refer to the *last* completed connection, and do account for keepalives. > 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. > Unfortunately, that really doesn't provide a lot of info. The reason I implemented it (the 2 copies) was to account for things like how many the _current_ process has handled since it's been alive. This is different from the total number for that _slot_ in the scoreboard file. I think the current implementation really reduces the amount of info that's useful since it tracks the _current_ use and not the culmulative (sp) use for that child, and that's what we are most interested in. The info about the last connection is nice, but not as useful as a inside look on the entire child activity. If the group thinks the *last* info is useful, I would prefer adding 2 more longs to the scoreboard to hold _that_ info as well... But this is a dangerous road to start down (making the scoreboard bigger) unless we really think the info is useful. Personally, if I had to choose, I would prefer the the way it was over this... it gives me more insight. -- Jim Jagielski << jim@jaguNET.com >> | "That's a Smith & Wesson, ** jaguNET Access Services ** | and you've had your six" Email: info@jaguNET.com | - James Bond ++ http://www.jaguNET.com/ +++ Voice/Fax: 410-931-3157 ++