> Hardware LB in front of the squids is good, but consider
> having the squids
> handle the backend balancing on their own (as parent caches
> or with the
> new rproxy patches
> (http://squid.sourceforge.net/rproxy/backend.html)).
> The squids are very good at detecting overloads and downings and
> reassign the request. It also reduces the load on the LB switch.
interesting, I'll take a look at that...
> If maximum caching is the goal, that will help. Keep in
> mind, though,
> that by the time you send, receive, and react to ICP, you've
> added a heap
> of latency to that request. (That's fine on the client end,
> where a hit
> at almost any cost is faster than contacting the origin server for a
> miss.) Assuming the front-end caches have enough space for your most
> popular files, letting them act alone will drastically
> improve response
> time with only a minor impact on the overall hit rate.
unfortunately each cache server's capacity will only hold a portion of the
popular files. latency is not as much of an issue as maximum amount of
content cached.
> What do your cache_peer and cache_peer_access lines look like?
on 10.1.8.111:
--------------
cache_peer 10.1.8.112 sibling 80 3130 proxy-only
cache_peer_access 10.1.8.112 allow all
on 10.1.8.112:
--------------
cache_peer 10.1.8.111 sibling 80 3130 proxy-only
cache_peer_access 10.1.8.111 allow all
still getting no ICP traffic...
-d-
Received on Fri Aug 31 2001 - 12:49:42 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:01:57 MST