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
