RE: [squid-users] Alteon + squid

From: Wei Keong <chooweikeong@dont-contact.us>
Date: Wed, 17 Jul 2002 16:53:14 +0800 (Singapore Standard Time)

> I use cache-digests and ICP, which means that I _do_
> have some duplicate content, it shouldn't be much though.

Well, depending on your squid config, your servers might have more
duplicated objects than you thought. We are running cache digest
too (cache_peer, sibling, proxy-only, no-query). We realise that the
objects are actually duplicated within the peers, probably as a result of
users force refresh the browser.

> I think you're getting the problem from the wrong angle.
> If you really want to do url-based load-balancing
> (and I really think you shouldn't, it's not worth the effort)

Emm... sounds like you tried before. Care to share?

> I think you'd better do it at the client level.
> Doing otherwise means IMO to go into big BIG hairy messes
> when you account for NTLM auth and its damned
> connection-orientedness.

We are running transparent proxy/caching (Alteon WCR) and we cant do it at
the client side. Also, we dont really required authentication.

> You can for instance set up two (or three or four) services
> on the virtual server on the alteon, on different ports.
> Then set up a proxy.pac so that it goes preferably on
> one of those (and the others as backup) depending
> on the target host.
>
> Define two a server-groups with your proxies pooled by target domain
> and a virtual server, then 2 services on different ports
> pointing to the two server-groups. DO NOT USE complex real-server
> selection metrics. Use leastconns or bandwidth, and BY ALL MEANS
> turn session affinity (persistent binding) ON.

I managed to test this on my AD3 (WebOS 8.3) too. But, running virtual
server will break our transparent proxy... Ideally, we want to run domain
based (host header) WCR on the AD3 (works well with the transparent WCR),
but somehow cant get it to work. Have you tried implementing this before?

Rgds,
Wei Keong

On Wed, 17 Jul 2002, Chemolli Francesco (USI) wrote:

> > just a thought i've developed... when u are using the
> > Alteon load balancer, how do u ensure that u don't
> > have duplicate information across your cache
> > servers.... do u do this by using Squid cache-peering
> > feature... this is important, as u wouldn't want to
> > have the same object on each cache server... as u
> > maximise efficiency and hit rate...
>
> I use cache-digests and ICP, which means that I _do_
> have some duplicate content, it shouldn't be much though.
>
> I think you're getting the problem from the wrong angle.
> If you really want to do url-based load-balancing
> (and I really think you shouldn't, it's not worth the effort),
> I think you'd better do it at the client level.
> Doing otherwise means IMO to go into big BIG hairy messes
> when you account for NTLM auth and its damned
> connection-orientedness.
>
> You can for instance set up two (or three or four) services
> on the virtual server on the alteon, on different ports.
> Then set up a proxy.pac so that it goes preferably on
> one of those (and the others as backup) depending
> on the target host.
>
> So for instance, supposing that you want to balance
> .com vs. non-.com:
>
> Define two a server-groups with your proxies pooled by target domain
> and a virtual server, then 2 services on different ports
> pointing to the two server-groups. DO NOT USE complex real-server
> selection metrics. Use leastconns or bandwidth, and BY ALL MEANS
> turn session affinity (persistent binding) ON.
>
> Do a proxy.pac which is something like this:
>
> function findProxyForUrl(host,url) {
> if (host.substring(whatever_args)==".com")
> return "PROXY VIP:3128; PROXY VIP:3129";
> return "PROXY VIP:3129; PROXY VIP:3128";
> }
>
> I'll leave fixing up the broken syntax as an exercise to the reader.
>
>
> This said, I recommend NOT to do this. The duplicate content is
> not much in my experience
> (provided that you use cache-peer's proxy-only option),
> and it's not really worth the split in processing power and resources.
>
> --
> /kinkie
>
Received on Wed Jul 17 2002 - 02:55:07 MDT

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