Peering Squid Caches
by Jennifer Vesperman09/17/2001
A Squid cache can be set to check other Squid servers (its peers) for cached web pages before going direct to the requested page. Peering your Squid caches can provide faster responses and lower costs. Cache peers exchange cached objects, returning them to the users faster and reducing upstream bandwidth costs.
Sources
Squid first looks for requested objects in its own cache. If the object is not in the cache, then Squid must retrieve it from another source. To oversimplify the algorithm: Squid creates an ordered list of possible sources.
This list consists of parent(s), sibling(s), and the origin server(s). Squid attempts to fetch the object from each server in order until it is successful, one of the servers responds with a 404 (object not found), or there are no more sources to try.
Access controls and ICP queries modify the list using these rules:
If
never_directsettings forbid Squid to contact the origin server(s) directly, Squid removes the origin server from the list.If
always_directsettings require Squid to use the origin server, Squid removes all peers from the list.If
cache_peer_accessprevents a particular peer from being queried for this object, the peer is removed from the list.Remaining peers are queried. Siblings (but not parents) that answer in the negative are removed.
Any remaining peers in the list are ordered according to speed of response.
Squid maintains a small database of response-times for origin servers. If going direct is an option, the origin server is placed in the list based on average weighted response time.
Communicating between peers
Peers need to tell each other which objects are in their caches. ICP and HTCP allow instant queries and responses. Digests are snapshots of what is currently in the cache.
ICP and HTCP
Squid usually uses the ICP protocol to communicate between caches, and can use HTCP if both caches are configured for it. ICP and HTCP are similar enough that, unless noted otherwise, the article uses ICP to describe both.
|
Related articles: Using Squid on Intermittent Connections Installing and Configuring Squid
|
When Squid receives a request for an object that is not in its cache, it sends an ICP query packet to each of its configured peers. If at least one peer says it has the object, Squid requests the object from the fastest of these peers. If all the peers answer "no" or fail to respond before a timeout setting, Squid requests the object from the origin or fails, depending on never_direct settings.
ICP uses untracked UDP packets. Because untracked UDP packets may be lost, dropped, or damaged, Squid uses a timeout value. Any queries which are not responded to in this time are assumed to be lost, and Squid drops those peers from its list for this request.
Squid uses a dynamic ICP timeout by default, but this can be overridden with icp_query_timeout or capped with icp_maximum_query_timeout if you find that the values that Squid calculates are suboptimal for your environment.
Digests
A cache digest is a block of URI keys which represents the set of objects the cache holds. The URIs are run through a deterministic algorithm which compacts the data and makes the keys. Digests are exchanged with digest-capable peers, and are used to determine whether a peer is likely to have a requested object.
Digests are subject to false hits and false misses, depending on the frequency of the exchange, but they reduce the immediate network traffic and are useful if the bandwidth between peers is narrow or unreliable.
Configuring a parent cache
Use a parent cache if you want to reduce your upstream costs and make page collection faster for your users, especially if the users are in groups which can have child caches.
Set up ACLs (Access Control List) for your downstream users:
acl cache_users src 192.168.0.0/255.255.0.0Give those users HTTP access to your cache:
http_access allow cache_usersThey will also require MISS access, otherwise they'll be denied if requests aren't in the cache:
miss_access allow cache_usersGive them ICP access as well:
icp_access allow cache_users
Pages: 1, 2 |
