Re: why send ICP queries for hierarchy_stoplist matches?

On Sep 3, 1:01pm, Duane Wessels wrote:
} Subject: Re: why send ICP queries for hierarchy_stoplist matches?
}
}
} On Fri, 3 Sep 1999, Don Lewis wrote:
}
} >
} > I'm running Squid 2.2.STABLE4 behind a firewall, so I have it
} > configured with a never_direct acl that matches anything outside the
} > firewall in order to get Squid to fetch through its parent cache, which
} > is outside the firewall. I noticed that Squid does an ICP query for
} > URLs that match its hierarchy_stoplist, which it would normally fetch
} > directly if it weren't behind the firewall. This ICP query seems kind
} > of wasteful, since the parent cache won't have the object cached. It
} > seems to me that it would be better to just do the http query for
} > anything that is known to be uncacheable.
}
} The reason that the ICP query happens is because you might have
} multiple parent caches when behind a firewall.
}
} We probably could optimize for the case when you have only one
} parent.
}
} I guess you can also achieve the same effect by adding 'no-query'
} to your cache_peer line.

If there is only one parent, then 'no-query' is probably the best
optimization.

If the object is potentially cacheable and you have multiple parents,
or you have siblings, then it is worthwhile to do the ICP query.

If all the servers are under your administrative control, and you know
the object isn't cacheable because of the no_cache directive (which
probably matches hierarchy_stoplist), it's a pessimization to to
the ICP query since it will always fail. This can be especially bad
if the parent cache is far away.

This isn't really a problem for me yet, but may become an issue
in the future.

Another question that comes to mind is if Squid is blocked from
doing a direct query by "never_direct", and but the URL matches
the setting of hierarchy_stoplist, where does Squid send the ICP
queries? Does it send them to the siblings as well as parents?
I'm just curious, because I assume that this is probably suitably
controllable with cache_peer_domain/neighbor_type_domain.
Received on Tue Sep 07 1999 - 08:56:28 MDT