> -----Original Message-----
> From: H [mailto:h@matik.com.br]
> Sent: Thursday, December 15, 2005 10:09 AM
> To: squid-users@squid-cache.org
> Subject: Re: [squid-users] prefer parent peer
>
>
> On Thursday 15 December 2005 15:32, Mark Elsen wrote:
> > > Is there a way to configure Squid 2 to always first try
> fetching through
> > > the (only) parent, and if that fails, then go direct?
> > >
> > > Here's what I have now, and this fails miserably if
> x.x.x.x is down:
> > >
> > > cache_peer x.x.x.x parent 3128 3130 no-query default
> > > never_direct allow all
> >
> > Use :
> >
> > always_direct deny all
> >
>
>
> and then the access will fail also when the parent eventually
> is not up or can
> not serv at this moment, it dos not matter if you use
> always_direct deny or
> never_direct allow, both fail when parent fail
>
Not entirely true. From the default Squid conf:
# You need to be aware that "always_direct deny foo" is NOT the same thing as "never_direct allow foo".
"always_direct deny all" will not all prevent traffic from going direct. It will just prevent traffic from ALWAYS going direct.
> appearently squid queries ever the parent first so no need to
> use any other
> parameter
>
This is true for most requests. There are classes of requests that Squid prefers to send direct. Look into the nonhierarchical_direct to send those requests to a parent by preference (not necessity).
> may be you like using proxy-only in order not caching the object twice
>
> H.
>
This is the setup that I used to prefer a parent:
always_direct allow all # default behavior
nonhierarchical_direct off
prefer_direct off # default behavior
It's not perfect, in that some traffic (less than 1%) does manage to go direct, but it allows the client cache to continue surfing even if the parent stops responding. Using "always_direct deny all" might be more of a requirement if the parent cache doesn't reply to ICP queries. I don't know.
Chris
Received on Thu Dec 15 2005 - 18:18:01 MST
This archive was generated by hypermail pre-2.1.9 : Sat Dec 31 2005 - 12:00:02 MST