On 12/8/06, H. Peter Anvin <hpa@zytor.com> wrote:
quoted text
> There is another thing that probably will be required, and I'm not sure
> if something in front of Apache (like Squid) rather than behind it can
> easily deal with: on timeout, the process needs to continue in order to
> feed the cache.  Otherwise, you're still in a failure scenario as soon
> as timeout happens.

I would think this would be a great deal easier to handle in an
arm's-length "accelerator" than in the origin server.  Only restart
the hit to the origin server if you think that something has actually
gone wrong there.  Serve stale data to the client if you have to.
From the page I quoted:

"In addition an option to shortcut the cache revalidation of
frequently accessed objects is added, making further requests
immediately return as a cache hit while a cache revalidation is
pending. This may temporarily give slightly stale information to the
clients, but at the same time allows for optimal response time while a
frequently accessed object is being revalidated. This too is an
optimization only intended for accelerators, and only for accelerators
where minimizing request latency is morer important than freshness."

I don't know how sophisticated this logic is currently, but I would
think that it wouldn't be that hard to tune up.

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html