Re: [squid-users] Connect directly if parent cache fails

On 21/02/11 20:27, Yucong Sun (叶雨飞) wrote:
> Hi there,
>
> I've been trying to do the same thing, but squid always tries too hard
> on parents.
>
> You can do this as what I do:
>
> Have a local squid with "always_direct allow all" listening on another
> port as the last entry of cache_peer with a default .
>
> when squid tried the peers above and failed, it will fall back to the
> last one which runs on the same computer, so should (suppose) always
> work as long as your local network works..
>

Nice :)

If you have 3.1 or later the "too hard" can be mediated somewhat by
connect-fail-limit=N and connect-timeout-N options on the cache_peer line.

They can reduce the default 10 retries down to something faster and less
aggressive. Timeout can take a while, so 4-5 seconds is a conservative
value which helps retain good web service times.

>
> On Sun, Feb 20, 2011 at 10:18 PM, Tom Tux wrote:
>> Hi
>>
>> Is my scenario in general possible to implement (connect directly, if
>> the one and only cache_peer fails)?
>>
>> Thanks a lot.
>> Tom
>>
>> 2011/2/17 Tom Tux:
>>> Hi Amos
>>>
>>> This doesn't work as expected. I removed the "never_direct" entry (I
>>> was unsure, how "strong" it is in the configuration...) and dropped
>>> also the hierarchy_stoplist-directive.

never_direct and always_direct are absolutes.
The other related options are more best-effort attempts and modifiers of
how selection happens.

>>>
>>> But if the cache_peer fails, it either connects directly (if I have
>>> set nonhierarchical_direct on) or the connect will fail.

Eh, that directive is supposed to only affect the special CONNECT and a
few other rare request types. Part of their specialness in current Squid
is being bad at failover (thus the default).
Are you seeing it control other common requests?

peer_direct should be the main factor. Pushing the direct choice to
happen before or after the cache_peer are tried.

Yucong has a solid configuration outlined, if a bit complex. So that
looks like a workable scenario if you are not able to spend any time
finding the bottom of this failure.

I think give the connect-fail-limit some tuning and a look-see at which
requests are failing and why. Your scenario is perfectly reasonable and
indeed commonly desired, so *should* work easily. Why it is not is a bit
mystifying.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.11
   Beta testers wanted for 3.2.0.5