Peering Squid Caches
Pages: 1, 2

Tell your cache-clients the cache's hostname, HTTP and ICP ports, and why they should be using it. A knowledgeable user is more likely to use the cache.

CAVEAT: The more caches you have downstream of you, the lower your hit-rate as a parent. Caches downstream of you will cache what they can, and pass up requests only for content that they do not have, or that is hard to cache. Every hit is still a benefit, even if the rate is low.

If your bandwidth is paid by the byte, you'll find that even a low hit-rate will cover the hardware and operating expenses.

Configuring a child cache

Some ISPs give a cost reduction if you use their parent. Parent caches may contain the page you're about to want, providing faster service.

You will need:

• The parent's hostname (such as, proxy.cache.example.org)
• The HTTP port (Often 3128. Sometimes 8080.)
• The ICP port (usually 3130). Use port 7 (echo) and the no_query configuration option if your parent doesn't support ICP.

For each parent you have, add a line like this to your squid.conf:
cache_peer hostname parent HTTP_port ICP_port [OPTIONS]
eg: cache_peer proxy.cache.example.org parent 3128 3130 no_query no-digest

Related Reading Web Caching By Duane Wessels Table of Contents Index Sample Chapter Full Description Read Online -- Safari

If you have one parent, use the no-query and no-digest configuration options. If you're always going to request the object from the parent, there's no need to check for the object.

If you have multiple parents, ICP queries can improve performance. An example with two parents:

1. One parent says yes, the other says no. We use the one that said yes.

2. Both parents said yes. They both have it, so use the one that answered first. It's likely to be fastest.

3. Both parents said no. Again, whoever answered first.

4. One parent failed to respond. We go with the other one. The parent that didn't answer may have failed or be temporarily unreachable.

CAUTION: When a peer fails to respond to ICP queries in dead_peer_timeout seconds, Squid assumes it is unavailable or unreachable until it sees another ICP response from that peer. While a peer is in this "presumed dead" state, Squid will send ICP queries, but won't wait for it to answer. Squid will base decisions on the responses of the "live" peers.

If all your parents are "dead" according to this test and Squid is not configured to go direct, Squid will not be able to return objects that are not in its cache.

Configuring a sibling cache

Sibling caches work well where you have groups of users. Each group's local proxy shares the cache with other proxies, only "going forward" to a parent or origin server if none of the caches have a fresh copy of the requested object.

Use sibling caches if several caches are behind some sort of bottleneck but have good connections to each other.

Siblings can group together to allow several smaller computers to simulate one expensive computer and serve as a larger proxy.

To allow another cache to use you as a sibling, configure your cache as if it were a parent cache, but instead of giving MISS access, deny it to your siblings.
acl sibling1 src 192.168.44.55/255.255.255.255
miss_access deny sibling1

To use another cache as a sibling, both caches must support either ICP/HTCP or cache digests. These allow Squid to check for objects in other caches.
The cache_peer entry looks like this:
cache_peer hostname sibling HTTP_port ICP_port [OPTIONS]
cache_peer sibling1.myinternalnet.org sibling 3128 3130 proxy-only

Note the proxy-only option. Normally, caching objects fetched from a sibling is a waste of disk space. If the bandwidth to a sibling is narrow, lossy or expensive, consider leaving the option out and caching objects from that sibling.

Caveats and gotchas

FALSE HITS: (ICP only) Because ICP does not communicate request headers (only the URI is presented in an ICP query), it is possible for a peer to return an affirmative for a given URI but not be able to satisfy the request from cache.

• cache1 sends an ICP query to cache2 for http://www.example.org/index.html.

• cache2 has a cached copy of the object (87,376 seconds old), and answers in the affirmative.

• cache1 then issues the request to cache2, but the request headers contain "Max-Age: 86400"). cache2's copy is too old to satisfy this request.

• If cache1 has miss_access on cache2, then cache2 will go forward to the origin server (or a parent) and fetch a new copy,
  If not, cache2 will return a 504 HTTP response and cache1 will have to select a new source for the object.

HTCP incorporates the request headers into the query packet, and is thus almost immune to false hits -- although they are still theoretically possible under rare circumstances.

Further reading

• RFC2186 - Internet Cache Protocol (ICP), version 2 http://www.ietf.org/rfc/rfc2186.txt
• RFC2187 - Application of Internet Cache Protocol (ICP), version 2http://www.ietf.org/rfc/rfc2187.txt
• RFC2756 - Hyper Text Caching Protocol (HTCP/0.0) ftp://ftp.isi.edu/in-notes/rfc2756.txt
• "Squid, a user's guide" http://squid-docs.sourceforge.net/latest/html/book1.htm
• "Squid configuration manual" http://squid.visolve.com/squidconf.html
• $SQUID-HOME/etc/squid.conf

Jennifer Vesperman is the author of Essential CVS. She writes for the O'Reilly Network, the Linux Documentation Project, and occasionally Linux.Com.

---

Return to the Linux DevCenter.