On Wed, 2005-02-23 at 00:00 +0100, Henrik Nordstrom wrote:
> Many are confused about the relations of cache_peer, never_direct and
> always_direct etc.
>
> cache_peer defines possible paths where Squid MAY forward the request.
>
> cache_peer_access/cache_peer_domain limits when these paths may be
> considered.
>
> always_direct forces Squid to ignore all peers and always go direct for
> the request.
>
> never_direct (when always_direct is not in effect) tells Squid that it may
> not go direct.
>
> when neither always_direct or never_direct is in effect (the default
> situation) Squid is free to choose whatever path it sees most fit for the
> request, and will do this based on a number of criterias.
>
> - type of request
> - hierachy_stoplist
> - prefer_direct on/off
> - ICP status of the possible peers
> - TCP status of the possible peers
> - netdb information
> - etc..
>
> With the goal of finding a reasonable balance between global cache hit
> ratio and request latency.
>
> Normally it selects
>
> 1. The "best" ICP peer or Digest HIT peer.
>
> 2. Direct
>
> 3. Some parent (default, round-robin etc..)
>
> If prefer_direct off then 2 and 3 switches place.
>
> In never_direct then the picture looks somewhat different
>
> 1. The "best" ICP peer or Digest HIT peer.
>
> 2. Some parent (default, round-robin etc..)
>
> 3. All parents.
>
> If always_direct then the picture becomes simply
>
> 1. Direct
>
> Regards
> Henrik
Many many thanks Henrik, this is a very interesting explanation for me!
Thus, knowing now that I should use never_direct and why, supposing that
I want to use a frontend squid that makes a kind of layer 7 switching, I
guess I could use never_direct, together with cache_peer_access ACL
based on file extension, thus I could direct some files to the backend
squid (configuring it like a parent for those request based on certain
file extensions) using proxy-only and another ICP parent (not the
backend one) for the file extensions it should treat on its own!
Well, Henrik, once again many thanks!
Marco
Received on Wed Feb 23 2005 - 01:43:06 MST
This archive was generated by hypermail pre-2.1.9 : Tue Mar 01 2005 - 12:00:02 MST