[jira] [Commented] (TS-4235) Deprecate fuzzy cache revalidation ?

["Christoph Keller (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-4235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177350#comment-15177350 ] 

Christoph Keller commented on TS-4235:
--------------------------------------

I'd drop this feature in favour of [TS-4237|https://issues.apache.org/jira/browse/TS-4237] but that's just my personal opinion. 
I haven't seen this feature help us so far but that may be due to the fact that we're just starting to use trafficserver and don't serve much traffic with it so far. I guess in some cases it could even confuse operations teams by those additional requests not triggered by a real client. 

> Deprecate fuzzy cache revalidation ?
> ------------------------------------
>
>                 Key: TS-4235
>                 URL: https://issues.apache.org/jira/browse/TS-4235
>             Project: Traffic Server
>          Issue Type: Improvement
>          Components: Configuration, HTTP
>            Reporter: Leif Hedstrom
>            Assignee: Leif Hedstrom
>             Fix For: 6.2.0
>
>
> I'm starting this as a discussion here. I think there are good reasons to deprecate (for now) and later remove the fuzz logic. These configs are currently in place:
> {code}
>   {RECT_CONFIG, "proxy.config.http.cache.fuzz.time", RECD_INT, "240", RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>   {RECT_CONFIG, "proxy.config.http.cache.fuzz.min_time", RECD_INT, "0", RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>   {RECT_CONFIG, "proxy.config.http.cache.fuzz.probability", RECD_FLOAT, "0.005", RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
> {code}
> The reason for eliminating these are:
> 1) They are difficult to setup correctly, particularly if you have a mix of various cache TTL on objects.
> 2) Currently, they have next to no value, since you lock out all other readers from the object anyways. So you are likely to benefit / use this only for objects which are infrequently accessed.
> 3) With the new proxy.config.http.cache.open_write_fail_action it's possible that #2 improves, but in that case, I'd argue that if you allow it to serve stale, you are better off letting it expire and not "prematurely" revalidate the object.
> 4) It seems to cause confusing behavior as it is today (with default settings), e.g. anything with less than 240s TTL is likely to trip up and prematurely expire long before intended (this is why we added the proxy.config.http.cache.fuzz.min_time option, but it's disabled by default, and makes configuration even more complicated).
> So what does everyone think? Is anyone actually using and relying on the fuzz logic? It feels better to spend some time on adding more features to the fail_action feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)