rob05c edited a comment on pull request #6017: URL: https://github.com/apache/trafficcontrol/pull/6017#issuecomment-879533836
@alficles > The race here is not "how long after queuing does a cache poll", though, it's "how long after data modification are updates queued". It's actually all four. It's how long after data modifications are made, and an operator queues, and t3c runs, and t3c requests /update_status, and t3c determines that it needs to update, and t3c requests the data endpoint. Unless all of that happens in less time than the cache (which defaults to 1s, but can be made lower), the update will get the most recent changes. Which is why it's extremely unlikely. But regardless, there's a simple solution, as above, queue time and max-age. > This is practically only a concern in scripted changes Correct. > If we wanted to bust the race, though, all we'd have to do is invalidate the cache when updates are queued. That's probably feasible if we want to avoid operators needing to dance around the cache. @rob05c , does that seem feasible? Invalidation on the server side doesn't perfectly solve the problem, because there can be multiple TO's. But max-age does. > This seems like a clear performance win. There are operational concerns, but it seems to have appropriate controls that allow people to make the right decision for their hardware and operational situation. It supports no-cache requests that allow scripts to ensure no caching. Even a moderately large CDN might see multiple orders of magnitude of performance improvement with very conservative values like just a few milliseconds. +1 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
