RE: [squid-users] SQUID and WCCP V1 in an ISP setup

As Joe pointed out, WCCP uses a hash algorithm to compute which cache server
the request will go so it doesn't really need to keep track where the
objects go.

-----Original Message-----
From: Aaron Seelye [mailto:AaronS@et-n-m.com]
Sent: Friday, December 07, 2001 12:31 AM
To: squid-users@squid-cache.org
Subject: RE: [squid-users] SQUID and WCCP V1 in an ISP setup

Just a question Joe, how does WCCP keep track of where everybody went? I
know when you do per-destination load balancing (as opposed to per-packet),
it only keeps track of the destinations for five minutes. With many clients
being rerouted using wccp, I'd imagine the number of destination hosts gets
quite large. I would think that it would just keep a small number of those
hosts in memory for it's rerouting and balance the others normally. Over
time (a day or so) I'd think that without peer-caching, those squid boxes
would become around 75% identical in their cache contents. Am I missing
something?

Aaron

> -----Original Message-----
> From: francisv@dagupan.com [mailto:francisv@dagupan.com]
> Sent: Thursday, December 06, 2001 8:10 AM
> To: squid-users@squid-cache.org
> Subject: RE: [squid-users] SQUID and WCCP V1 in an ISP setup
>
>
> I get it now, thanks Joe.
>
> -----Original Message-----
> From: Joe Cooper [mailto:joe@swelltech.com]
> Sent: Thursday, December 06, 2001 11:48 PM
> To: francisv@dagupan.com
> Cc: squid-users@squid-cache.org
> Subject: Re: [squid-users] SQUID and WCCP V1 in an ISP setup
>
> If you're using WCCP to balance requests across multiple
> caches then no
> cache member will /ever/ have an object that another cache wants.
>
> To copy from my original message:
>
> > Cache peering is counter-productive in your environment. WCCP will
> > divide traffic in such a way that data sharing is not required--it
> > splits traffic based on destination IP of the client
> requests so every
> > cache will contain unique data.
>
> The key in that paragraph (which I guess I should have put before the
> inflammatory statement that cache peering is
> counter-productive, since
> it blinded you to the rest of the paragraph ;-), is that the
> traffic is
> divided based on destination IP from the client request--so
> there never
> be a request for the same data from more than one cache.
>
> What I've just said isn't always true--and I'm sure someone
> will pipe up
> with why it's not if I don't point it out now. The 'nevers' in the
> above statements are not true if you take one cache out of
> the group or
> add a new cache into the group--or if you change the IP
> ordering of the
> web caches in the cluster. In any of those cases (which are isolated
> and shouldn't happen on a regular basis) there will be some
> overlap of
> cache data among the caches--and requests for objects that
> are already
> in one cache may reach another cache. In which case cache
> peering might
> be useful for about two days--and then it would become
> counter-productive again.
>
> Cache peering then, is a complete and utter waste of cycles and local
> network bandwidth. Every peer request will always come back
> as a MISS.
> Always. No exceptions (except the silly exceptions
> mentioned in the
> previous paragraph). So every miss on a local cache will
> have to wait
> for misses to come back from its peers before going out to the origin
> server. We don't want that, as it is counter-productive.
>
> Make sense now?
>
>
> francisv@dagupan.com wrote:
>
> > Joe,
> >
> > I don't understand why cache peering is counter-productive
> here. If a
> cache
> > member has the object, why not share it among other cache members?
> >
>
> [ snipped ]
>
Received on Thu Dec 06 2001 - 09:33:57 MST