Re: Statistics for access times

> 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!

True, I've done measurements of this nature for an httpd server and
you start to get reasonable numbers (within 10% of actual) for
response sizes greater than 64K. But it depends on the window size
and network latency (the higher the latency and window size, the more
optimistic the response time for a given response size).

> 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?

You'd have to poke around in the kernel. The problem is a little more
difficult when we get persistent connections (multiple requests served
over the same connection).

> * 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.

That's right, the network bandwidth is basically divided by the number
of active connections. So you have to determine when connections
overlap and multiply the individual throughputs to get the actual
network throughput (well, actually an approximation).

...tai
Received on Tue Sep 03 1996 - 11:25:42 MDT