cache empties itself?
ric at digitalmarbles.com
Fri Apr 4 05:59:19 CEST 2008
On Apr 3, 2008, at 7:46 PM, Michael S. Fischer wrote:
> On Thu, Apr 3, 2008 at 7:37 PM, Ricardo Newbery <ric at digitalmarbles.com
> > wrote:
>> URL versioning is usually not appropriate for html
>> pages or other primary resources that are intended to be reached
>> directly by
>> the end user and whose URLs must not change.
> Back to square one. Are these latter resources dynamic, or are they
> - If they are dynamic, neither your own proxies nor upstream proxies
> should be caching the content.
> - If they are static, then they should be cacheable for the same
> amount of time all the way upstream (modulo protected URLs).
> I've haven't yet seen a defensible need for varying cache lifetimes,
> depending on the proximity of the proxy to the origin server, as this
> request seems to be. Of course, I'm open to being convinced otherwise
Well, first of all you're setting up a false dichotomy. Not
everything fits neatly into your apparent definitions of dynamic
versus static. Your definitions appear to exclude the use case where
you have cacheable content that is subject to change at unpredictable
intervals but which is otherwise fairly "static" for some length of
Sometimes, in such a case, serving stale content for some time after
an edit is an acceptable compromise between performance and freshness
but often it is not. And sometimes, impacting overall performance by
hitting the backend for every such request is also undesirable.
Thankfully, those are not the only choices. With a combination of
PURGE requests and something like Surrogate-Control (or hardcoded
behavior in your reverse-proxy config), you can still insure immediate
freshness (or whatever level of freshness you require) without forcing
your backend to do all the work.
More information about the varnish-misc