On Sat, Sep 12, 2020 at 9:56 PM Batanun B <[email protected]> wrote: > > > Arguably, if you use Varnish to cache responses, you might as well > > always tell your backend not to serve from cache. Because if a soft > > purge moves you inside the grace period, there's no guarantee that the > > next hit will happen before the object leaves the grace period. At > > this point this will no longer trigger a background fetch... > > Well, the caching in the backend is not on the same level as the Varnish > cache. In Varnish, a single request results in a single object to cache. In > the backend, a single request can result in hundreds or thousands of separate > lookups (some involving separate http calls to other services), each cachable > with their own unique key. And most of these objects are reused from the > cache for other requests as well. And skipping that internal cache > completely, letting the backend do all these lookups and sub-requests every > single time a request comes in to the backend, that would be terrible for > performance. So we really only want to skip this internal cache in special > circumstances.
In this case you might want to coordinate your tiers with Last-Modified headers. Cached objects are immutable with Varnish, except for the timing attributes so my previous answer is still applicable: you can't record that an object was soft-purged by a VMOD. The bereq.is_bgfetch variable will tell you whether you are in the grace period but that's about it. Dridi _______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
