Squid's cache manager interface can provide you with some helpful statistics as well, which you can access either with the cachemgr.cgi program and a browser, or with the client program on the command line.
The server list (a slight misnomer) will report statistics about
your neighbour caches. To view this information from the command
line, use:
client cache_object://localhost/server_list | less
A subset of sample output is shown below.
Parent : uc.cache.nlanr.net/3128/3130
Status : Up
AVG RTT : 31 msec
ACK DEFICIT: 0
PINGS SENT : 0
PINGS ACKED: 36133 0%
FETCHES : 9765 27%
IGNORED : 9193 25%
Histogram of PINGS ACKED:
ICP_HIT : 2421 7%
ICP_MISS : 33712 93%
Last failed connect() at: 18/Aug/1997:01:50:56 -0700
DOMAIN LIST: com edu net org gov mil us
Parent : sv.cache.nlanr.net/3128/3130
Status : Up
AVG RTT : 69 msec
ACK DEFICIT: 0
PINGS SENT : 1007
PINGS ACKED: 964 96%
FETCHES : 398 41%
IGNORED : 322 33%
Histogram of PINGS ACKED:
ICP_HIT : 68 7%
ICP_MISS : 896 93%
DOMAIN LIST: au nz aq jp kr sg vn th tw lk
Squid will let you know if it thinks the neighbour is currently up or down. If a TCP connection attempt fails, Squid shows the time of the most recent failure near the bottom of this display. An important value to watch is the Average RTT, which is not simply a ping-based network RTT, but rather the average time taken to send an ICP query and receive an ICP reply. In other words, this value includes the time required by the peer to process the ICP message.
Ack Deficit is the number of consecutive unacknowledged ICP queries. If this number reaches 20, Squid will mark the peer as down. Pings Sent is the number of ICP queries sent to the peer, and Pings Acked is the number of replies received. Note that we are using multicast here, and Pings Sent only counts queries sent directly (via unicast) to the peer. Fetches is the number of HTTP requests forwarded to that neighbour. Ignored is the number of ICP replies that Squid has ignored, most likely because they arrived after Squid had already forwarded the request.
The histogram depicts the breakdown of the (non-ignored) ICP replies, with the percent based on the Pings Acked value, and not on the Pings Sent value.
Finally we display the domain list for each peer, as specified with the cache_host_domain directives. Note that we do not display the cache_host_acl configuration.
The client list tells you about your cache clients, including
other caches using yours as a parent or sibling, although they
are not identified as such because
there is no easy way to identify that the request came
from a browser versus another cache.
This information
is particularly useful if you have disabled ICP query logging.
To view the client list, select
the ``Client List'' menu option in the CGI program, or issue
the following Unix command:
client cache_object://localhost/client_list | less
Some sample output is shown below. For each client IP address,
Squid counts the number of requests for each cache result code,
and displays their percentages.
Address: 205.17.46.36
Name: 205.17.46.36
ICP Requests 293995
UDP_HIT 11879 4%
UDP_HIT_OBJ 14513 5%
UDP_MISS 267515 91%
UDP_INVALID 39 0%
UDP_MISS_NOFETCH 49 0%
HTTP Requests 40068
TCP_HIT 798 2%
TCP_MISS 30904 77%
TCP_REFRESH_HIT 1894 5%
TCP_REF_FAIL_HIT 36 0%
TCP_REFRESH_MISS 1646 4%
TCP_CLIENT_REFRESH 3116 8%
TCP_IMS_HIT 818 2%
ERR_READ_TIMEOUT 16 0%
ERR_READ_ERROR 35 0%
ERR_CLIENT_ABORT 257 1%
ERR_CONNECT_FAIL 425 1%
ERR_DNS_FAIL 106 0%
ERR_ZERO_SIZE_OBJECT 17 0%
Address: 195.30.27.114
Name: 195.30.27.114
HTTP Requests 1855
TCP_HIT 209 11%
TCP_MISS 1295 70%
TCP_REFRESH_HIT 95 5%
TCP_REFRESH_MISS 90 5%
TCP_CLIENT_REFRESH 106 6%
TCP_IMS_HIT 35 2%
ERR_CLIENT_ABORT 22 1%
ERR_CONNECT_FAIL 2 0%
ERR_DNS_FAIL 1 0%
The above numbers are real, but the IP addresses have been changed. The first client is obviously a peer cache because it uses ICP. Note that 9% of the ICP replies are HITs; approximately the same percent of remote hits in the previous section.
The second client does not use ICP, but that doesn't necessarily mean it is not a cache. It might just be configured to use the no-query and default options.
The Name field will most often just show the IP address, unless Squid has been configured to lookup fully-qualified domain names with the log_fqdn option.
Normally you should not have much reason to examine the network probe
database (aka ICMP measurements), other than to satisfy your own
curiosity. It is actually quite interesting to look at the data.
Select ``Network Probe Database'' from the cachemgr.cgi menu,
or issue the following command from a Unix shell:
client cache_object://localhost/stats/netdb | less
The output should resemble:
Network recv/sent RTT Hops Hostnames
198.62.160.0 2/ 2 22.0 7.0 www.jec.edu www.countrystars.com
uc.cache.nlanr.net 82.0 9.0
pb.cache.nlanr.net 84.0 9.0
sd.cache.nlanr.net 85.0 16.0
128.2.194.0 2/ 2 41.5 6.0 tom.cs.cmu.edu robotweb.ri.cmu.edu
pb.cache.nlanr.net 7.0 5.0
203.183.232.0 1/ 69 229.9 8.5 bbw.tokyoweb.or.jp powerhouse.co.jp
sv.cache.nlanr.net 184.0 8.0
194.77.86.0 9/ 23 466.9 9.6 www.ghg-verlag.com www.dom.de
pb.cache.nlanr.net 283.0 12.0
it.cache.nlanr.net 366.0 12.0
sd.cache.nlanr.net 388.0 11.0
uc.cache.nlanr.net 419.0 13.0
First of all note that hostnames are aggregated by ``/24'' networks. We assume that all hosts whose IP addresses have the same first three octets will have similar network measurements. In the example above we have only shown two hostnames per network, but in practice you will often see tens or hundreds of names per entry.
The lines starting with IP networks hold measurement data from
your local cache. We also count the number of pings sent and
received, although this information is not currently used in
the neighbour selection process. We calculate decaying averages for
the measured round trip time, and the estimated hop count. The RTT
measurements are straightforward. Squid estimates hop counts
by looking at the ip->ttl field of the ICMP reply packet, and
guessing at its initial value when sent from the originating host.
Because the hop count is averaged over time, and for different hosts,
we may end up with non-integer values. Recall that we only use the
RTT values in determining proximity, and not the hop counts.
The indented lines represent measurements returned by your neighbour caches in their ICP replies. These are listed in order of increasing RTT. Note that we won't necessarily have measurements for every peer cache. The measurements may time out, or may have failed to arrive.
The data above was taken from bo.cache.nlanr.net. For the first entry (e.g. www.countrystars.com) we can see that `BO' is closer than any of the listed neighbours. Even so, we will still use ICP for a subsequent request. However, unless one of the neighbours returns a RTT measurement lower than 22 milliseconds, `BO' would forward the request directly to the origin server.
The second entry shows that `PB' is closer than `BO' for
some servers in the cmu.edu domain.
Similarly, the third entry shows that `SV' is closer for
some servers located in Japan, reasonable since
traffic from `BO' to Japan likely routes through FIX-West anyway.
The final entry is interesting because `BO' has the lowest estimated hop count, but the largest measured RTT. Because we only use RTT to select, a request to one of those domains would very likely be forwarded to `PB'.
By default Squid keeps track of approximately 1000 networks in this database. For large caches, this value is probably too small, and you can configure its range yourself with the netdb_low and netdb_high configuration directives. The NLANR caches use values of 9900 and 10000 respectively. Also, the default netdb_ping_period is conservatively set at 5 minutes. You may want to increase the period to every one minute.