Squid_ The Definitive Guide - Duane Wessels [151]
LRU reference age
If the removal policy is lru, you'll also see this line. It shows the age of the oldest object in the LRU list.
store_check_cachable_stats: storeCheckCachable( ) Stats
This page displays a table of counters from the storeCheckCachable( ) function. It is called for most responses, just before Squid attempts to open a disk file for writing.
* * *
Tip
Squid knows that some responses can't be cached, based entirely on the request. These responses aren't included in the storeCheckCachable( ) statistics.
* * *
The table includes the following lines:
no.not_entry_cachable
The ENTRY_CACHABLE flag was cleared for some reason.
no.release_request
The RELEASE_REQUEST flag was set while reading the response. This may be due to an error (such as receiving a partial response) or to the rules of the transfer protocol.
In some versions of Squid, this counter is always zero because the storeReleaseRequest( ) function always clears the ENTRY_CACHABLE bit, causing such objects to be counted as no.not_entry_cachable instead.
no.wrong_content_length
The actual content length doesn't match the Content-Length header value.
In some versions of Squid, this counter is always zero because storeReleaseRequest( ) is always called if the response size doesn't match the expected content length.
no.negative_cached
The ENTRY_NEGCACHED flag was set. See the description for TCP_NEGATIVE_HIT in Section 13.2.1.
no.too_big
The response body was larger than the maximum_object_size value.
no.too_small
The response body was smaller than the minimum_object_size value.
no.private_key
The response has a private cache key, indicating that it can't be shared with other users.
no.too_many_open_files
The Squid process was low on free file descriptors.
no.too_many_open_fds
Squid had more than max_open_disk_fds opened at one time.
yes.default
The response was cachable because it did not meet any of the preceding criteria.
store_io: Store IO Interface Stats
This short table contains four lines related to allocating disk storage for a new response. For example:
Store IO Interface Stats
create.calls 2825670
create.select_fail 0
create.create_fail 0
create.success 2825670
create.calls
The number of calls to the function that creates a new disk file.
create.select_fail
The number of times that the create operation failed because the cache_dir selection algorithm did not select a cache directory. The default selection algorithm, least-load, fails if it thinks all cache directories are too busy.
create.create_fail
The number of times that the create operation failed at the storage layer. This may happen if the open( ) call returns an error or if the storage system (e.g., diskd) elects to not open a disk file for some reason (e.g., overload condition).
create.success
The number of times the create operation succeeded.
pconn: Persistent Connection Utilization Histograms
This page displays two histograms. The first is for client-side persistent connection usage. For example:
Client-side persistent connection counts:
req/
conn count
---- ---------
0 74292
1 14362705
2 3545955
3 2068486
4 1411423
5 1030023
6 778722
7 603649
8 474592
9 376154
10 301396
On the left is the number of requests per connection. On the right is the number of times a client connection had that many requests. Most likely, you'll see that one request/connection has the highest count and that the counts decrease as the number of requests/connection increases.
The second table has the same information, but for server-side HTTP connections. You should see the same sort of pattern here, with one request/connection having the highest count.
refresh: Refresh Algorithm Statistics
The refresh page shows a few tables relating to the freshness of cached objects. Internally, Squid keeps track of the way different modules use the refresh functions. The first table shows how many calls each module has made. The really interesting data is contained