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_queryconfiguration option if your parent doesn't support ICP.
For each parent you have, add a line like this to your
cache_peer hostname parent HTTP_port ICP_port [OPTIONS]
cache_peer proxy.cache.example.org parent 3128 3130 no_query no-digest
If you have one parent, use the
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:
One parent says yes, the other says no. We use the one that said yes.
Both parents said yes. They both have it, so use the one that answered first. It's likely to be fastest.
Both parents said no. Again, whoever answered first.
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.
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
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.
cache1sends an ICP query to
cache2has a cached copy of the object (87,376 seconds old), and answers in the affirmative.
cache1then issues the request to
cache2, but the request headers contain "Max-Age: 86400").
cache2's copy is too old to satisfy this request.
cache2will go forward to the origin server (or a parent) and fetch a new copy,
cache2will return a 504 HTTP response and
cache1will 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.
- 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
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.