An expected latency formula (fwd)

I sent this msg before but nothing came back. I read a recent email and
learned that it might be rejected somehow. Therefore I re-sent it. Sorry
if that causes any inconvenience.

Yee Man

---------- Forwarded message ----------
Date: Mon, 6 Jul 1998 17:36:11 -0400 (EDT)
From: Yee Man Chan <ymc@umich.edu>
To: squid-dev@ircache.net
Subject: An expected latency formula

Hi,

I am trying to derive a formula to find the expected latency of a client
using Squid. I am in particularly uncertain about what is TCP_IMS_MISS
means, tell me if I get anything wrong below.

Thanks
Yee Man

Here it is:

The formula is derived based on the following assumpitons:

1) Simple client-proxy-server model. No co-operative caching.
2) Disregard network failure and hardware failure.
3) HTTP headers are identical in size regardless the extra options
specified
4) Memory access time is neligible when compared to other I/O time.
5) HTTP reply other tahn 200 or 304 is disregarded

Please refer to ftp://ircache.nlanr.net/Traces/README for the definitions
of Access Log Tags. The percentage in the bracket shows the weight of each
response in a particular trace.

Key
c-p_t = client-proxy HTTP header RTT
p-s_t = proxy-server HTTP header RTT
obj_p-c_t = obj transfer time from proxy to client
obj_s-p_t = obj transfer time from server to proxy
load_s_t = server loads obj from disk to mem
load_p_t = proxy loads obj from disk to mem

Time spent on each of the following Squid response:

TCP_MEM_HIT time = c-p_t + obj_p-c_t (1.56%)

TCP_HIT time = load_p_t + c-p_t + obj_p-c_t (13.45%)

TCP_MISS/200 time = c-p_t + p-s_t + load_s_t + obj_s-p_t + obj_p-c_t
(33.94%)

TCP_MISS/304 time = c-p_t + p-s_t (4.10%)
comments: This happens when client issues an IMS req. The obj is not in
cache. The cache sends an IMS to server and the server says the obj is not
modified. Only header exchange is involved in this case.

TCP_REFRESH_HIT time = c-p_t + p-s_t + load_p_t + obj_p-c_t (13.49%)
comments: For every object that fails refresh test, Squid will send a IMS
req to original server. I observed that about 30% of requests failed the
test. And there is about 45% of THOSE requests are TCP_REFRESH_HIT. That
means 13.5% of ALL requests wasted p-s_t. An ideal refresh test
should have 0% TCP_REFRESH_HIT. Squid's refresh test is certainly not good
enough. However, I don't know any literature about refresh test in
WWW caching. There should be some in distributed computing.

TCP_REFRESH_MISS time = c-p_t + p-s_t + load_s_t + obj_s-p_t + obj_p-c_t
(16.72%)

TCP_IMS_HIT/200 time = TCP_HIT time (0.25%)
comments (updated): IMS reqs from clients are usually generated by the
client cache provided by Netscape or Explorer when the obj in client cache
fails browser's refresh test. When Squid receives this request, if the
object in cache is considered fresh after the refresh test, it will
then check the specified IMS date with the timestamp of the fresh object
in the cache. If the Squid's obj is more recent than the IMS date, Squid
will send the obj back to the client, this is TCP_IMS_HIT/200, otherwise,
it is TCP_IMS_HIT/304, only a header with "304 Not Modified" is returned
If the object is considered stale, Squid will do exactly the same thing as
in TCP_REFRESH_HIT or TCP_REFRESH_MISS.
After an inspection in Squid's source code. I find that TCP_IMS_MISS is an
extremely rare response (at most 1 in 100,000). It happens when there is
an IMS is made by the client. The obj requested is defected (last reply
status == 0) but is in Squid memory. Then Squid does the same thing as a
miss/200.

TCP_IMS_HIT/304 time = c-p_t (14.24%)

TCP_IMS_MISS time = TCP_MISS/200 time (0%)

The formula we want would be the probability expectation of all the
possible response times mentioned.
Received on Tue Jul 29 2003 - 13:15:51 MDT