Squid_ The Definitive Guide - Duane Wessels [180]
The mcast_icp_query_timeout directive specifies how long Squid should wait when counting replies to its fake probe queries. Why not just use this timeout when sending real multicast ICP queries? The reason is that Squid might be sending queries to both multicast and unicast neighbors.
The mcast_icp_query_timeout directive essentially controls how long Squid waits for replies to real multicast queries. Let's say you have an ICP multicast group with 10 neighbor caches, and that it typically takes 3000 msec for all 10 replies to arrive but only takes 1000 msec to receive 5 replies. If you set mcast_icp_query_timeout to 1000 msec, Squid's periodic probes will count 5 neighbors. Then, for a real multicast ICP query, Squid waits for only 5 replies from multicast responders. On average, this should take only 1000 milliseconds.
Another nice feature of this algorithm is that Squid does the right thing if, for some reason, all your multicast neighbors stop responding. In that case, Squid counts zero neighbors and doesn't wait for any replies from multicast responders.
* * *
Tip
Squid doesn't send multicast HTCP queries.
* * *
Syntax
mcast_icp_query_timeout milliseconds
Default
mcast_icp_query_timeout 2000
Example
mcast_icp_query_timeout 750
Related
icp_port, icp_query_timeout
Name
dead_peer_timeout
Synopsis
This is another directive that controls the way Squid waits for ICP/HTCP replies. Squid marks each of its peers as either dead (down) or alive (up). Squid uses ICP/HTCP replies (and other techniques) to determine a peer's state. If Squid doesn't receive any replies for the time specified by dead_peer_timeout , the peer is declared dead.
When a peer is declared dead, Squid continues to send it ICP/HTCP queries. However, it doesn't expect to receive replies. That is, a dead peer isn't included in the algorithm that decides when all ICP replies have been received. As soon as Squid receives an ICP/HTCP reply from a dead peer, its state is changed to alive.
Squid tends to be paranoid about the state of its peers. Additionally, Squid doesn't proactively monitor the peers when there are no client requests. When Squid has no occasion to send ICP/HTCP queries, the state of the peer is unknown. If Squid doesn't send any ICP/HTCP queries for an amount of time longer than dead_peer_timeout, Squid treats the peer as dead.
Syntax
dead_peer_timeout time-specification
Default
dead_peer_timeout 10 seconds
Example
dead_peer_timeout 30 seconds
Related
icp_port, htcp_port, icp_query_timeout
Name
hierarchy_stoplist
Synopsis
Every HTTP request that Squid receives is marked as either hierarchical or nonhierarchical. This terminology is somewhat confusing. A request is hierarchical when there is a possibility it could be a cache hit in one of the neighbors. In other words, if the information in the request indicates that the response may be cachable, the request is hierarchical. A request is marked nonhierarchical when Squid thinks there is no chance of getting a hit from a neighbor.
Squid uses the hierarchical flag to decide whether or not it should query neighbors for the request. If the request is hierarchical, Squid may perform ICP/HTCP queries, or use Cache Digests, to locate cache hits in neighbors. Otherwise, Squid may forward the request directly to the origin server or select a parent based on some other technique.
Squid has a few hardcoded rules that determine if a request is hierarchical. For example, only GET requests are hierarchical. Squid never expects cache hits on non-GET requests. Another rule is that requests including authentication information are nonhierarchical. The hierarchy_stoplist directive allows you to customize the algorithm further. The stoplist is simply a list of strings. Squid searches the requested URL for these strings. The string comparison is case-sensitive. In the case of a match, the request becomes nonhierarchical. The default configuration is to search