The following are general guidelines for configuring leaf caches (those with only browsers as clients). We realize that these may not be appropriate for everyone, however.
cgi-bin and ?
so that your parent cache is not bothered with those requests.
Configuring a single parent cache is relatively straightforward. Most likely, as with any cache configuration, you would want to use the local_domain directive to indicate domains which you do not want to forward to the parent cache. We assume that the parent cache lies somewhere along your default path to the Internet (i.e. at your ISP). If the cache is not along your default path, you may want to consider it as a sibling instead of a parent.
For a single parent configuration, we normally do NOT recommend using ICP. In this case, the primary benefit of ICP would be that it can detect congestion and failure of the parent cache. Squid will monitor the TCP connections to the parent cache anyway. When a TCP connection fails, and Squid marks the parent down, your cache will forward requests directly to origin servers until the parent cache comes back up. The disadvantage to ICP is the added latency, which may or may not be significant, depending on the RTT to your parent cache.
Sample configuration:
local_domain mydomain.net
cache_host cache.isp.net parent 3128 3130 no-query default
Here we consider using multiple parent caches for load balancing. Instead of a single cache, your ISP (or whoever) may choose to have multiple caches for purposes of load balancing or redundancy. From your point of view, these parent caches are all equivalent and it does not particularly matter which one you use for any given request.
There are really two ways to support load balancing: either with ICP or with the round-robin flag. The advantage to using ICP is that the least-busy parent cache will likely be the first to send an ICP reply (all other things being equal). The disadvantage, again, is the additional latency. Using the round-robin flag avoids ICP delays. Without, ICP Squid will use the TCP connection status to mark parent caches as up or down.
Another disadvantage to not using round-robin and not ICP
is that the parent cache selected for a given URL is essentially
random. For example, http://www.nlanr.net/ may be forwarded
to cache1 the first time and then to cache3 the second time.
With ICP, your cache would know which of the caches already hold
the URL. If the parent caches themselves have sibling relationships
between themselves, then this becomes less of an issue. They will
check each other's caches before forwarding the request on to
the origin server.
Sample configuration with round-robin:
local_domain mydomain.net
cache_host cache1.isp.net parent 3128 3130 no-query round-robin
cache_host cache2.isp.net parent 3128 3130 no-query round-robin
cache_host cache3.isp.net parent 3128 3130 no-query round-robin
Sample configuration with ICP:
local_domain mydomain.net
cache_host cache1.isp.net parent 3128 3130
cache_host cache2.isp.net parent 3128 3130
cache_host cache3.isp.net parent 3128 3130
Here we consider multiple parent caches, but now for the purpose of request routing. Instead of all parents being equivalent, we now want to restrict which requests are forwarded to which parents. The cache_host_domain or cache_host_acl directives must be used to define which requests each parent can handle.
For example, lets assume that your ISP has a pair of caches.
One will be dedicated to caching URLs from the .com domain.
The other will hold all other domains. This is easily configured
as follows:
local_domain mydomain.net
cache_host cache1.isp.net parent 3128 3130 no-query default
cache_host cache2.isp.net parent 3128 3130 no-query default
cache_host_domain cache1.isp.net com
cache_host_domain cache2.isp.net !com
If you want to have sibling relationships with other caches, then you must utilize ICP. There are two important things to consider in this situation. First, is the ``access denied'' problem discussed above ( miss-access ). Either the group of siblings need to have the same refresh_pattern rules, or they should not use miss_access. Not using miss_access requires a fair amount of trust between all of the members.
Second, you should avoid sending large numbers of ICP queries for every request. When your cache must wait for a lot of replies, then the probability that at least one of the replies will not arrive becomes significant. If you plan to query every sibling for every request (i.e. no cache_host_domain restrictions), then we recommend keeping the group size small, say five to six members at the most.
Sample configuration:
local_domain mydomain.net
cache_host cache.isp1.net sibling 3128 3130
cache_host cache.isp2.net sibling 3128 3130
cache_host cache.isp3.net sibling 3128 3130
cache_host cache.isp4.net sibling 3128 3130
This might be a good situation to use multicast ICP if possible. Although multicast is not any less complex to configure, it would be less sensitive to the group size.
local_domain mydomain.net
cache_host 224.9.9.9 multicast 3128 3130 ttl=32
cache_host cache.isp1.net sibling 3128 3130 multicast-responder
cache_host cache.isp2.net sibling 3128 3130 multicast-responder
cache_host cache.isp3.net sibling 3128 3130 multicast-responder
cache_host cache.isp4.net sibling 3128 3130 multicast-responder
mcast_groups 224.9.9.9
The multicast cache_host allows your cache to send queries to
other group members, and the mcast_groups directive allows
your cache to receive queries from the others.
If you have both sibling and parent caches, then you will need to use ICP for the siblings at least. Depending upon the RTT to your parent(s), you may want to use ICP for them as well. For a single parent, we would probably recommend this configuration:
local_domain mydomain.net
cache_host cache.isp1.net parent 3128 3130 no-query default
cache_host cache.isp2.net sibling 3128 3130
cache_host cache.isp3.net sibling 3128 3130
cache_host cache.isp4.net sibling 3128 3130
For any request, this configuration would cause your
siblings to be queried first with ICP. If none of
the siblings has the URL, the request would be
forwarded to your parent cache (if it was believed to be up).