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
