From: rst@ai.mit.edu (Robert S. Thau)
Date: Fri, 17 Mar 95 10:30:49 EST
Message-Id: <9503171530.AA04729@volterra>
To: new-httpd@hyperreal.com
Cc: new-httpd@hyperreal.com
In-Reply-To: <199503170247.SAA02322@neon.netscape.com> (message from Rob
 McCool on Thu, 16 Mar 1995 18:47:50 -0800)
Subject: Re: Customizable logging
Sender: owner-new-httpd@hyperreal.com
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

   Date: Thu, 16 Mar 1995 18:47:50 -0800
   From: Rob McCool <robm@netscape.com>

   What I mean by "common" is merely the way that many servers implement
   it, like common gateway interface. It doesn't have to share anything
   in common with the current CLF aside from the fact that more than one
   server implements it.

Well, there are a lot of log analyzers that handle the current CLF, so
it would be good for that reason alone to keep the current format as
the out-of-the-box default.  (Disclosure of ulterior motive: I've got
an analyser of my own --- a *much* improved version of my metasummary
hack --- which I keep meaning to release once I find the time to
document it).

Aside from that, my only (minor!) concern with this stuff is that
whatever format is chosen not have too much overhead in the
implementations --- the last time I profiled a server, writing the log
file showed up as something like 7% of the time spent in the child
processes.

(On the other hand, this may have been due to gprof artifacts.  Gprof
doesn't know one call to write() from another --- it just sums them
all up and prorates the cost by number of calls to estimate the time
spent by caller --- so there may have been "spillover" from writes to
the socket.  In any case, if the implementation is about the cost of a
strftime() per logged transaction, that's not enough to notice).

rst