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 > > > > _______________________________________________ varnish-misc mailing list [email protected] http://projects.linpro.no/mailman/listinfo/varnish-misc
