Squid_ The Definitive Guide - Duane Wessels [141]
Cache Hits
The cache hit response time includes only requests logged as TCP_HIT, TCP_MEM_HIT, and TCP_OFFLINE_HIT. These are unvalidated cache hits served directly from Squid, without any communication to the origin server. Thus, your cache hit response time should be significantly less than the miss time. You should keep track of this value over time; if it climbs too high, your disk filesystem may be a performance bottleneck.
Near Hits
A near hit is a validated cache hit. It corresponds to TCP_REFRESH_HIT in access.log. For these, Squid contacts the origin server (or parent cache), which adds some latency to the response time. The server's response is a small 304 (Not Modified) message. Thus, the near hit response time is typically in between cache hits and cache misses.
Not-Modified Replies
This line shows the response times for requests logged as TCP_IMS_HIT. This occurs when the client sends a conditional (a.k.a. validation) request, and Squid serves a response without contacting the origin server. The name "not-modified" is somewhat misleading for this category because the status code received by the client isn't necessarily 304. For example, the client may send an If-modified-since request, and Squid has a fresh, cached response with a more recent modification time. Squid knows that its response is fresh and that the client's copy is stale. In this case, the client receives a 200 (OK) reply with the new object data.
DNS Lookups
The DNS service time shows how long it takes, on average, to query the DNS. This includes both name-to-address and address-to-name lookups. It doesn't include IP- and FQDN-cache hits, however. DNS queries can be a significant source of latency. If you experience performance problems with Squid, be sure to check this value. If you see a high median service time (i.e., around five seconds), make sure your primary DNS server (usually listed in /etc/resolv.conf) is up and running.
ICP Queries
The ICP query time represents the elapsed time between an ICP query and response that causes Squid to select the corresponding neighbor as the next hop. Thus, it includes only requests logged as PARENT_HIT, SIBLING_HIT, FIRST_PARENT_MISS, and CLOSEST_PARENT_MISS. This value may not be a good estimate of the overall ICP response time because ICP query/response transactions that don't result in Squid selecting a neighbor are ignored. Due to a bug in Squid Versions 2.5.STABLE1 and earlier, ICP response time statistics aren't collected, and these values always appear as 0.
The Resource usage section includes a few statistics relating to CPU and memory usage:
Resource usage for squid:
UP Time: 1840478.681 seconds
CPU Time: 70571.874 seconds
CPU Usage: 3.83%
CPU Usage, 5 minute avg: 1.33%
CPU Usage, 60 minute avg: 4.41%
Process Data Segment Size via sbrk( ): 342739 KB
Maximum Resident Size: 345612 KB
Page faults with physical i/o: 65375
UP Time
This line simply shows the amount of time this Squid process has been running. It is expressed in seconds.
CPU Time
The amount of CPU time used by Squid, also in seconds. This value comes from the getrusage( ) system call, which might not be available on all operating systems.
CPU Usage
This section has three CPU Usage lines. The first is the CPU Time value divided by the UP Time value. It is a long-term average CPU usage measurement. The next two lines show the CPU usage for the last five minutes and the last hour.
Process Data Segment Size via sbrk( )
This line offers an estimate of Squid's process size. sbrk( ) is a low-level system call used by the memory allocation library (malloc( )). The sbrk( ) technique provides only an estimate, which usually differs from values reported by programs such as ps and top. When the sbrk( ) value is greater than the Maximum Resident Size (discussed next), the Squid process is probably page faulting, and performance may be degrading.
Maximum Resident Size
This is another estimate of memory usage and process size. The maximum resident set size (RSS) value comes from