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

From: <francisv@dont-contact.us>
Date: Fri, 7 Dec 2001 00:09:48 +0800

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:10:07 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:05:15 MST