cache empties itself?
varnish-list at itiva.com
Tue Apr 8 17:26:26 CEST 2008
Ricardo Newbery wrote:
> On Apr 7, 2008, at 10:30 PM, DHF wrote:
>> Ricardo Newbery wrote:
>>> On Apr 7, 2008, at 5:22 PM, Michael S. Fischer wrote:
>>>> Sure, but this is also the sort of content that can be cached back
>>>> upstream using ordinary HTTP headers.
>>> No, it cannot. Again, the use case is dynamically-generated
>>> content that is subject to change at unpredictable intervals but
>>> which is otherwise fairly "static" for some length of time, and
>>> where serving stale content after a change is unacceptable.
>>> "Ordinary" HTTP headers just don't solve that use case without
>>> unnecessary loading of the backend.
>> Isn't this what if-modified-since requests are for? 304 not modified
>> is a pretty small request/response, though I can understand the
>> tendency to want to push it out to the frontend caches. I would
>> think the management overhead of maintaining two seperate expirations
>> wouldn't be worth the extra hassle just to save yourself some ims
>> requests to a backend. Unless of course varnish doesn't support ims
>> requests in a usable way, I haven't actually tested it myself.
> Unless things have changed recently, Varnish support for IMS is
> mixed. Varnish supports IMS for cache hits but not for cache misses
> unless you tweak the vcl to pass them in vcl_miss. Varnish will not
> generate an IMS to revalidate it's own cache.
Good to know.
> Also it is not necessarily true that generating a 304 response is
> always light impact. I'm not sure about the Drupal case, but at least
> for Plone there can be a significant performance hit even when just
> calculating the Last-Modified date. The hit is usually lighter than
> that required for generating the full response but for high-traffic
> sites, it's still a significant consideration.
> But the most significant issue is that IMS doesn't help in the
> slightest to lighten the load of *new* requests to your backend. IMS
> requests are only helpful if you already have the content in your own
> browser cache -- or in an intermediate proxy cache server (for proxies
> that support IMS to revalidate their own cache).
The intermediate proxy was the case I was thinking about, but you are
correct, if there is no intermediate proxy and varnish frontends don't
revalidate with ims requests then the whole plan is screwed.
> Regarding the potential management overhead... this is not relevant to
> the question of whether this strategy would increase your site's
> performance. Management overhead is a separate question, and not an
> easy one to answer in the general case. The overhead might be a
> problem for some. But I know in my own case, the overhead required to
> manage this sort of thing is actually pretty trivial.
How do you manage the split ttl's? Do you send a purge after a page has
changed or have you crafted another way to force a revalidation of
More information about the varnish-misc