Re: [squid-users] cache peer proxy-only - is there a middle ground?

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.
>
Received on Tue Feb 05 2008 - 08:23:08 MST