RE: [squid-users] squid parents setup

Thank you, Don. I will try this asap and see if i can make our proxies work.
Thanks you also to Torsten.

Thanks team,
-botp

-----Original Message-----
From: BAARDA, Don [mailto:don.baarda@baesystems.com]
Sent: Monday, July 16, 2001 8:27 AM
To: '"Pe�a, Botp"'; squid-users@squid-cache.org
Subject: RE: [squid-users] squid parents setup

G'day,

> -----Original Message-----
> From: "Pe�a, Botp" [SMTP:botp@delmonte-phil.com]
> Sent: Saturday, July 14, 2001 7:01 PM
> To: squid-users@squid-cache.org
> Subject: [squid-users] squid parents setup
>
> Hi Team:
>
> I plan to setup the ff proxy parents:
>
> proxy1
> proxy2
> proxy3
>
> Proxy1 and proxy2 are given top priority and will round robin (sort of)
> request from siblings. While proxy1 and proxy2 are up (or at least one of
> them), siblings should NOT query proxy3. Siblings will only query proxy3
> if
> proxy1 and proxy2 are down. The reason for this is that proxy3 has a very
> slow link and it should only be used as a last option. I am thinking in a
> way similar to the way the DNS MX priority works.
>
> Is this possible? Hints, pls, for a newbie.
>
        Provided the upstream proxies support ICP, you can do even better
than you are planning. Try the following on Squid 2.4 and above;

        cache_peer proxy1 parent 3128 3130 weight=4 no-digest
no-netdb-exchange round-robin
        cache_peer proxy2 parent 3128 3130 weight=4 no-digest
no-netdb-exchange round-robin
        cache_peer proxy3 parent 3128 3130 weight=4 no-digest
no-netdb-exchange default
        #icp_query_timeout 1000
        maximum_icp_query_timeout 1000
        prefer_direct off

        This will load-balance the links to the upstream proxies by choosing
the parent with the fastest ICP response. This load-balancing will
compensate for different link speeds and other traffic. It will also favour
the first parent that responds with a hit, but IMHO, hits are rare enough
that this won't affect the overall load balancing. The ICP query timeout
also ensures that a parent getting overloaded by ICP_HITs gets excluded
until it's link calms down.

        This _will_ introduce ICP latency, but it is limited to 1 second by
the maximum_icp_query_timeout. Parents that exceed the query timeout are not
used (HIT or MISS), unless all parents exceed the timeout, in which case it
falls back to round-robin'ing proxy1 and proxy2. If any proxies go down,
they simply get excluded from the parent selection process. It will only go
direct if all parents are down.

        You can adjust the bias for each proxy by adjusting the weights. You
can adjust the balance between ICP balancing and round-robin balancing by
adjusting the maximum_icp_query_timeout, which also limits the maximum ICP
latency. If getting hits on parents makes a difference and they support
digests, you can remove the "no-digest" options to avoid ICP latency's when
a parent has a digest-hit. If Squids dynamic ICP timeout calculation is
giving you too much round-robin selection, you can use icp_query_timeout
instead of maximum_icp_query_timeout.

        One of the side effects of using ICP is you get a feel for how good
your upstream proxies are from their ICP ping times and hit ratios.

        If your parent's don't support ICP, you can try using the UDP echo
port. If that is blocked you have to resort to an ICP <-> ICMP mapping
proxy... which I have if anyone is interested.

> Thanks in advance,
> -botp
Received on Sun Jul 15 2001 - 19:52:16 MDT