suggesting bugwash topic: hit-for-pass vs. hit-for-miss

[Nils Goroll]

Hi,

Geoff any myself would want to get ahead with the design aspects of this issue,
so we'd appreciate if we could discuss it during the next bugwash.

It would be great if anyone interested could review the background info - my
initial email, quoted in full below, has the top-level overview.

For the option of a vcl_hit based decision,
https://github.com/varnishcache/varnish-cache/issues/1799 is relevant also.

Thank you, Nils

On 02/09/16 20:10, Nils Goroll wrote:
> (quick brain dump before I need to rush out)
> 
> Geoff discovered this interesting consequence of a recent important change of
> phk and we just spent an hour to discuss this:
> 
> before commit 9f272127c6fba76e6758d7ab7ba6527d9aad98b0, a hit-for-pass object
> lead to a pass, not it's a miss. IIUC the discussions we had on a trip to
> Amsterdam, phks main motivation was to eliminate the potentially deadly effect
> unintentionally created hfps had on cache efficiency: No matter what, for the
> lifetime of the hfp, all requests hitting that object became passes.
> 
> so, in short
> 
> - previously: an uncacheable response wins and sticks for its ttl
> - now:        an cacheable response wins and sticks for its ttl
> 
> or eben shorter:
> 
> - previously:	hit-for-pass
> - now:		hit-for-miss
> 
> From the perspective of a cache, the "now" case seems clearly favorable, but now
> Geoff has discovered that the reverse is true for a case which is important to
> one of our projects:
> 
> - varnish is running in "do how the backend says" mode
> - backend devs know when to make responses uncacheable
> - a huge (600MB) backend response is uncacheable, but client-validatable
> 
> so this is the case for the previous semantics:
> 
> - 1st request creates the hfp
> - 2nd request from client carries INM
>   - gets passed with INM
>   - 304 from backend goes to client
> 
> What we have now is:
> 
> - 1st request creates the hfm (hit-for-miss)
> - 2nd request is a miss
>   - INM gets removed
>   - backend sends 600MB unnecessarily
> 
> We've thought about a couple of options which I want to write down before they
> expire from my cache:
> 
> * decide in vcl_hit
> 
>    sub vcl_hit {
> 	if (obj.uncacheable) {
> 		if (obj.http.Criterium) {
> 			return (miss);
> 		} else {
> 			return (pass);
> 		}
> 	   }
>   }
> 
> * Do not strip INM/IMS for miss and have a bereq property if it was a misspass
> 
>   - core code keeps INM/IMS
>   - builtin.vcl strips them in vcl_miss
>   - can check for hitpass in vcl_miss
>   - any 304 backend response forced as uncacheable
>     - interesting detail: can it still create a hfp object ?
> 
>   BUT: how would we know in vcl_miss if we see
>   *client* inm/ims or varnish-generated inm/ims ?
> 
> So at this point I only see the YAS option.
> 
> Nils
> 
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>