(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@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
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@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev