Elli Albek wrote:
Thanks, this is basically the solution. Can I do header override in squid to
add this if the origin does not send this header?
Not early enough for it to matter. The header alteration done by Squid
happens just prior to the reply being sent to the client. The caching
decisions happen far earlier than this header addition.
Would it make sense for squid to keep the state of the origin server for a
few seconds, so it dose not have to contact it when it is not accessible on
each individual request? Something like:
1. If origin responds to a request, set origin state to active.
2. If origin does not respond to a request, set origin state to "not
active". This expires after a few seconds.
3. If origin state is not defined, it is assumed to be active.
4. If origin state is "not active", do not forward more than one request at
a time.
Sounds little bit like a can of worms :)
Squid already does. The limit for the current stable releases is that 10
failed requests are needed to mark a peer dead. This is fixed to a
configurable measure in the current development releases Squid 3.1.0.9+
beta, 2.HEAD(2.8 alpha), 3.HEAD(3.2 alpha).
All squid also do these:
The failed responses from each DNS located IP are marked and the IP is
not tried again. Turn balance_on_multiple_ip off for this to become visible.
If --enable-icmp is used RTT times between Squid and each source
server are recorded for future routing selections.
The monitor* options to cache_peer turn on active HTTP-level 'ping'
operations to each peer at regular intervals for quicker dead detection
on low-throughput networks and quicker re-alive detection in all cases.
Elli
-----Original Message-----
From: Chris Woodfield [mailto:rekoil@xxxxxxxxxxxxx]
Sent: Thursday, June 25, 2009 9:36 AM
To: Amos Jeffries; Myles Merrell
Cc: Squid Users
Subject: Re: Serving from the cache when the origin server
crashes
Take a careful look at the stale-if-error Cache-control header, as
described below:
http://tools.ietf.org/html/draft-nottingham-http-stale-if-error-01
In a nutshell, this allows you to force squid to serve up objects if
the origin is down, even if those objects are stale, for a
configurable number of seconds after the object's original stale
timestamp.
However, you'll still have the overhead of squid attempting to reach
the origin, failing, then serving up the stale object on each request
- as such, I'd highly recommend making sure that if you use this, you
shut down the server in such a way that it generates an ICMP
Destination Unreachable reply when squid attempts to connect.
If you take the server off the air completely, squid will have to wait
for network timeouts before returning the stale content, which your
users will notice.
Of course, you'll need to make sure that squid has your site cached in
its entirety - it can't retrieve not-cached content from a dead
server :)
Amos, can you confirm that 3.x supports this? I'm using it in 2.7.
-C
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
Current Beta Squid 3.1.0.9
