Re: [squid-users] Serving from the cache when the origin server crashes

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_at_semihuman.com]
> Sent: Thursday, June 25, 2009 9:36 AM
> To: Amos Jeffries; Myles Merrell
> Cc: Squid Users
> Subject: Re: [squid-users] 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