cache empties itself?

[DHF]

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 
cached objects?

--Dave
>
> Ric
>
>
>
>