Ah, I’m using Varnish 4.1, guess might have to look into >= 5.2. Thanks! :)
Best Regards, Danila > On 12 Apr 2018, at 12:25, Guillaume Quintard <[email protected]> > wrote: > > bereq.is_bgfetch? > > -- > Guillaume Quintard > > On Thu, Apr 12, 2018, 09:24 Danila Vershinin <[email protected] > <mailto:[email protected]>> wrote: > Couldn’t really find anything useful besides obj.hits which indirectly tells > us it’s a background fetch. So: > > sub vcl_deliver { > if (req.http.grace == "normal(limited)" && obj.hits == 0 && > req.http.Varied-Header = 'value1') { > set req.http.Varied-Header = 'value2’; > unset req.http.grace; > return (restart); > } > } > > ? :) > > Best Regards, > Danila > >> On 12 Apr 2018, at 00:24, Guillaume Quintard <[email protected] >> <mailto:[email protected]>> wrote: >> >> There's a beresp attribute for that last one (I'm on mobile, so I'm going to >> point you to man vcl :-)) >> >> -- >> Guillaume Quintard >> >> On Wed, Apr 11, 2018, 22:39 Danila Vershinin <[email protected] >> <mailto:[email protected]>> wrote: >> So I guess I’m looking into having one background fetch trigger another >> background fetch (to sequentially refresh different object variants). In >> this fashion: >> >> 1. Client PURGE request will do softpurge.softpurge(); return(restart); with >> GET method, etc. which will all lead to "return deliver()" in limited grace >> logic to fire background fetch . >> >> 2. Then in background fetch: >> → in its vcl_deliver() - the current object variation has already entered >> cache, so setting varied header to value2, removing grace limited flag and >> calling restart(). This way it should continue revalidation for the other >> object variant >> → we land inside limited grace logic again (as it’s a different object >> variant) and return deliver() again thus firing off second background fetch >> (which will refresh second object variant). >> >> So the standard grace logic + something like this: >> >> sub vcl_deliver { >> if (req.http.grace == "normal(limited)" && req.http.Varied-Header = >> 'value1') { >> set req.http.Varied-Header = 'value2’; >> unset req.http.grace; >> return (restart); >> } >> } >> >> However, it won’t work at least because req.http.grace flag will be set for >> both the background fetch and the request that kicked it off. (it will be >> there in vcl_deliver of both). >> Question is how can we tell if we are inside background fetch? >> >> Best Regards, >> Danila >> >>> On 11 Apr 2018, at 12:37, Guillaume Quintard >>> <[email protected] <mailto:[email protected]>> >>> wrote: >>> >>> Hi, >>> >>> That's indeed correct, a purge will kill all variations, and the restart >>> only fetches one. >>> >>> The req.hash_always_miss trick however only kills/revalidate one variation. >>> >>> At this moment, we have no way to purge/revalidate all the object under one >>> hash key. >>> >>> -- >>> Guillaume Quintard >>> >>> On Wed, Apr 11, 2018 at 11:26 AM, Danila Vershinin <[email protected] >>> <mailto:[email protected]>> wrote: >>> Hi Guillaume, >>> >>> A bit puzzled on something. If we use Vary: by some header.. am I correct >>> that we need multiple restarts to refresh each object variation? >>> >>> Since the background fetch would only refresh the variation that matched >>> initial purge request. >>> >>> Sent from my iPhone >>> >>> On 9 Apr 2018, at 12:18, Guillaume Quintard <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> Hi, >>>> >>>> You can purge then set the method to GET then restart. Would that work for >>>> you? >>>> >>>> Other way is to use req.hash_always_miss that will only revalidate if we >>>> are able to fetch a new object. >>>> >>>> -- >>>> Guillaume Quintard >>>> >>>> On Sat, Apr 7, 2018 at 12:10 PM, Danila Vershinin <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> Hi, >>>> >>>> What I work with: >>>> >>>> * Grace mode configured to be 60 seconds when backend is healthy >>>> * Using softpurge module to adjust TTL to 0 upon PURGE. >>>> >>>> The whole idea is increasing chances that visitors will get cached page >>>> after cache was PURGEd for a page. >>>> >>>> Standard piece: >>>> sub vcl_hit { >>>> if (obj.ttl >= 0s) { >>>> # normal hit >>>> return (deliver); >>>> } >>>> >>>> if (std.healthy(req.backend_hint)) { >>>> # Backend is healthy. Limit age to 60s. >>>> if (obj.ttl + 60s > 0s) { >>>> set req.http.grace = "normal(limited)"; >>>> return (deliver); >>>> } else { >>>> return(fetch); >>>> } >>>> } else { >>>> # ... >>>> } >>>> } >>>> And use of softpurge: >>>> >>>> sub vcl_miss { >>>> if (req.method == "PURGE") { >>>> softpurge.softpurge(); >>>> return (synth(200, "Successful softpurge")); >>>> } >>>> } >>>> >>>> sub vcl_hit { >>>> if (req.method == "PURGE") { >>>> softpurge.softpurge(); >>>> return (synth(200, "Successful softpurge")); >>>> } >>>> } >>>> >>>> >>>> Current behaviour: >>>> >>>> * send PURGE for cached page >>>> * Visitor goes to the page within 60 seconds and sees a stale cached page >>>> (triggering background refresh) >>>> * Further visits to the page will show refreshed page >>>> >>>> What I’m looking for: >>>> >>>> Trigger the background refresh right after PURGE while still leveraging >>>> grace mode :) That is, serve stale cache for only as long as it takes to >>>> actually generate the new page, and not wait for 60 seconds: >>>> >>>> * upon PURGE: set TTL to 0 (softpurge) + trigger background page request >>>> (possible?) >>>> * serve stale cache only while the page is generated >>>> >>>> I could have adjusted the “healthy backend grace period” to lower than >>>> 60s, but I’m basically checking to see if it’s possible to refresh >>>> “nearly” immediately in this kind of setup. >>>> >>>> Hope I made any sense :) >>>> >>>> Best Regards, >>>> Danila >>>> >>>> >>>> _______________________________________________ >>>> varnish-misc mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >>>> <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc> >>>> >>> >> >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
