Yes, we would us using cache digests to keep the ICP/multicast traffic
from becoming a bottleneck. Another benefit of cache digests is that
there will be a certain level of content duplication - if server A
caches an object, and server B gets a request for the same object
before if refreshes A's digest, the object will live on both servers,
which helps with the flash-crowd issue.
Then the question becomes this - if a server gets a request for an
object and has multiple cache digests that contain it, will the
decision use normal peer selection metrics?
-C
On Feb 5, 2008, at 6:57 AM, Amos Jeffries wrote:
Chris Woodfield wrote:
Hi all,
I'm facing an issue where we'd like to implement cache peering on
our squid farms, primarily to leverage the combined disk capacity
across all our boxes into a larger cache. I would presume that this
requires the use of the proxy-only directive to avoid content
duplication. However, this has raised the issue of server overload
- there's a very real possibility that a single hot object, if it
only lives on a single server, could overload that server with
requests from all the other peers in the event of a flash crowd.
I'd like to find some middle ground.
I'm wondering if there's a way to configure squid such that content
retrieved from peers is cached locally, but for a much shorter
period of time than content the cache retrieves directly. Is this
possible within squid, or should this be a feature request?
Squid contains a few methods for reduction of ICP requests.
Primarily the use of Cache Digests and to a lesser degree multicast-
ICP.
http://wiki.squid-cache.org/SquidFaq/CacheDigests
I think you possibly may be able to hack some ACLs that prevent disk
storage but leave items in the hot-memory cache. Though I have never
looked at that myself.
Amos
--
Please use Squid 2.6STABLE17+ or 3.0STABLE1+
There are serious security advisories out on all earlier releases.
