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

Sudheer Vinukonda commented on TS-4235:
---------------------------------------

Looks like I'm a little late here, but, I'm +1 on this :)

> 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)

Reply via email to