oreilly.comSafari Books Online.Conferences.


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,
  • 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 parent 3128 3130 no_query no-digest

Related Reading

Web CachingWeb Caching
By Duane Wessels
Table of Contents
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
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 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

  • 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

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.

Linux Online Certification

Linux/Unix System Administration Certificate Series
Linux/Unix System Administration Certificate Series — This course series targets both beginning and intermediate Linux/Unix users who want to acquire advanced system administration skills, and to back those skills up with a Certificate from the University of Illinois Office of Continuing Education.

Enroll today!

Linux Resources
  • Linux Online
  • The Linux FAQ
  • Linux Kernel Archives
  • Kernel Traffic

  • Sponsored by: