This can also be approached by sending the request to an intermediary "fanout"/request duplication endpoint. That way, the backends will always send the purge request to a single location, which then duplicates the requests to the related varnish nodes/clusters.
On Tue, Jan 24, 2017 at 1:31 PM, Jan Hugo Prins | BetterBe < [email protected]> wrote: > The problem is that asking the backend to purge is not an option because > that would not scale. If we would want to do that we need to know at the > backend how many varnish nodes the cluster has and how to reach them all to > purge the object effectively. Scaling the landscape would very soon become > a big nightmare. > > The solution you provide here sounds like something that is programmable > by someone familiar with VCL. VCL is completely new to me so I will start > creating a flow diagram to see if I can understand that way what you wrote > down. If you have any example code that would help me in the right > direction I would be very happy. > > Best regards, > Jan Hugo Prins > > > On 01/24/2017 11:35 AM, Guillaume Quintard wrote: > > Yes, you can: > - look for a match, and if you find one, note the etag, then restart. If > no match is found, fetch and deliver > - pass to the backend, if the etag doesn't match what you noted, ban the > object. Note the new etag, restart again > - if the new etag matches the one sent by the client, synthesize a 304, > otherwise deliver > > But, is that really worth it? And is it easier than asking the backend to > purge? > > > -- > Guillaume Quintard > > On Tue, Jan 24, 2017 at 11:19 AM, Jan Hugo Prins | BetterBe < > [email protected]> wrote: > >> Is it possible in any way to force the check before the result is send to >> the client? >> >> Jan Hugo >> >> >> >> On 01/24/2017 10:17 AM, Guillaume Quintard wrote: >> >> Hello, >> >> Indeed, with this vcl code, the object is checked asynchronously. So, if >> the check fails, the user that triggered the check will have received the >> outdated object. It may or may not be an issue depending on your use case. >> >> Note that you can reduce the TTL further. >> >> On Jan 24, 2017 03:11, "Jan Hugo Prins | BetterBe" <[email protected]> >> wrote: >> >>> After reading this mail and doing a lot more searching in the >>> mailinglist and on the web, I think it is actually rather simple. At least >>> I think that I'm seeing the correct behaviour. I'm not sure though, it >>> could be that the response is first generated and that the origin is only >>> checked after the response has been send to the client. What I have now in >>> my vcl_backend_response is nothing more then: >>> >>> sub vcl_backend_response { >>> if (beresp.http.Cache-Control ~ "must-revalidate") { >>> set beresp.ttl = 1s; >>> set beresp.keep = 3600s; >>> set beresp.grace = 3600s; >>> } >>> return (deliver); >>> } >>> >>> >>> Jan Hugo Prins >>> >>> >>> >>> On 01/23/2017 02:20 PM, Geoff Simmons wrote: >>> >>> On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote: >>> >>> Somewhere I found an old Trac Wiki document that describes >>> something like this, but I can't figure out if this has been >>> implemented or not. >>> https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8 >>> >>> That >>> >>> Wiki page is obsolete -- it was about an experimental branch that >>> was developed while Varnish 3 was the released version. >>> >>> (Maybe we should delete the Wiki page, it's not the first time someone >>> has been led astray.) >>> >>> Varnish has supported 304 responses to client requests with >>> If-Modified-Since/If-None-Match for as long as I've known about it >>> (going back to Varnish 2). Backend conditional requests have been >>> supported since Varnish 4. >>> >>> However, by default that doesn't quite work as your flow chart >>> indicates, if I've understood it correctly. If the client request is >>> for a cached response with an unelapsed TTL, then Varnish delivers the >>> cached response unconditionally, without re-validating the response >>> with the backend. Conditional requests to backends are done for the >>> fetch after the TTL elapses. >>> >>> That's the default, but I believe you can get your own VCL to >>> implement re-validation after cache hits. I haven't tried that myself >>> -- maybe someone reading the list has some working VCL they can share? >>> >>> >>> Best, >>> Geoff >>> >>> -- >>> >>> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and >>> Storage consultant* >>> [image: BetterBe - Transforming automotive leasing worldwide] >>> <https://www.betterbe.com> >>> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694 >>> <+31%20%280%29%2053%2048%2000%20694> >>> 7547 AN Enschede *E* [email protected] >>> CC no. 08097527 >>> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000> >>> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951> >>> www.betterbe.com >>> BetterBe accepts no liability for the content of this email, or for the >>> consequences of any actions taken on the basis of the information provided, >>> unless that information is subsequently confirmed in writing. If you are >>> not the intended recipient you are notified that disclosing, copying, >>> distributing or taking any action in reliance on the contents of this >>> information is strictly prohibited. >>> _______________________________________________ varnish-misc mailing >>> list [email protected] https://www.varnish-cache.org/ >>> lists/mailman/listinfo/varnish-misc >> >> -- >> >> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and Storage >> consultant* >> [image: BetterBe - Transforming automotive leasing worldwide] >> <https://www.betterbe.com> >> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694 >> <+31%20%280%29%2053%2048%2000%20694> >> 7547 AN Enschede *E* [email protected] >> CC no. 08097527 >> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000> >> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951> >> www.betterbe.com >> BetterBe accepts no liability for the content of this email, or for the >> consequences of any actions taken on the basis of the information provided, >> unless that information is subsequently confirmed in writing. If you are >> not the intended recipient you are notified that disclosing, copying, >> distributing or taking any action in reliance on the contents of this >> information is strictly prohibited. >> > -- > > Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and Storage > consultant* > [image: BetterBe - Transforming automotive leasing worldwide] > <https://www.betterbe.com> > Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694 > <+31%20%280%29%2053%2048%2000%20694> > 7547 AN Enschede *E* [email protected] > CC no. 08097527 > <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000> > *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951> www.betterbe.com > BetterBe accepts no liability for the content of this email, or for the > consequences of any actions taken on the basis of the information provided, > unless that information is subsequently confirmed in writing. If you are > not the intended recipient you are notified that disclosing, copying, > distributing or taking any action in reliance on the contents of this > information is strictly prohibited. > > _______________________________________________ > varnish-misc mailing list > [email protected] > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >
_______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
