In article <01BB96AB.05B45920@ar.tic.ch>, andrew@tic.CH (Andrew Richards) writes:
>
>My question: I've been looking at the stats scripts on
>http://www.nlanr.net/Squid/Scripts. (Aside/tip: They didn't work quite as
>described, but using "access-extract.pl -h access.log > summary;
>access-summary.pl summary" seems to work nicely). I'm very
>impressed with the scripts, but there's one thing that I consider
>to be "missing", namely, that there is no figure given for an overall
>access-time. This is something that was really useful in Netscape,
>which gave two figures - the average access time and the estimated
>access time without a proxy/cache.
>
Squid's native log format (not the emulated one) contains the access time
in milliseconds in the second column ($2).
There are two major problems with this number:
* It is calculated before closing the socket. This means that the time
necessary for flushing the TCP buffer is not included. This has great
impact on requests which fit entirely into the TCP buffer, which are
logged as being served almost instantaniously!
I'd like to fix this, but my UNIX programming skills are not enough.
To do the right thing, one has to find out when the TCP buffer has been
flushed. The problem is that the socket has the O_NDELAY flag set, so
the close() call returns immediately. I guess it's not allowed to use
select() after that on the semi-closed filedescriptor, right?
Does anybody know of a way squid can detect when the fd is really closed?
* Simultaneous connections. If a user who is connected over a 28k8 serial
line requests a HTML page with images, Netscape (e.g.) requests 4 of these
images simultaneously. This makes the logged access times bigger. So your
connection is generally faster than these numbers want you to believe.
I have given considerable thought to both of these issues, for inclusion in
my awk logfile analysis script. If anybody has any ideas, please contact me.
Regards, Richard.
Received on Sat Aug 31 1996 - 12:46:01 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:32:53 MST