4 ms·

If the TTL starts at 86400 and then declines to 0 before resetting.. this is a fairly common caching strategy... it ensures the cache will expire for all client

If the TTL starts at 86400 and then declines to 0 before resetting.. this is a fairly common caching strategy... it ensures the cache will expire for all clients at around the same time. For example, if you want the client's cache to expire at midnight everyday.

adastra22 4y ago
Is that really common? That sounds like a recipe for disaster.
- Kinrany 4y ago
  You could use the same mechanism to spread out the load
- doctor_eval 4y ago
  Yeah, sounds like a self-inflicted variant of the Thundering Herd Problem https://en.wikipedia.org/wiki/Thundering_herd_problem https://en.wikipedia.org/wiki/Thundering_herd_problem
_cenw 4y ago
That's a terrible idea. Source: Implemented global TTL in our own caching DNS in front of kube-dns (which is horrible if you, among other things, have node containers with no DNS caching; i still have a pcap with 20000+ queries for A in s3.amazonaws.com in a 0.2s span) before coredns was a thing. The CPU spikes were huge, but remained hidden for a long time due to metrics resolution. But eventually it got bad enough that clients ended up not getting responses.
- rgbrenner 4y ago
  There are circumstances where that’s the right strategy. For example, GitHub may be using it to ensure two requests for two different files in a repo receive the same version of the repo. Not saying they’re doing that.. just explaining the cache strategy. An explanation isn’t a recommendation for you to go out and apply it to everything. Source: founded and operated a cdn for 5 years of my life.
  - _cenw 4y ago
    As long as you key the expiration to something, be that the client IP or the repository, you're probably fine. Having your entire customer base do their cache expiration request within the same small time span is not amazing though. You can already get consistent views of raw.github by looking up the HEAD commit and requesting your files from that commit directly, though.

adastra22 4y ago

Is that really common? That sounds like a recipe for disaster.

Kinrany 4y ago
You could use the same mechanism to spread out the load
doctor_eval 4y ago
Yeah, sounds like a self-inflicted variant of the Thundering Herd Problem https://en.wikipedia.org/wiki/Thundering_herd_problem https://en.wikipedia.org/wiki/Thundering_herd_problem

_cenw 4y ago

That's a terrible idea. Source: Implemented global TTL in our own caching DNS in front of kube-dns (which is horrible if you, among other things, have node containers with no DNS caching; i still have a pcap with 20000+ queries for A in s3.amazonaws.com in a 0.2s span) before coredns was a thing. The CPU spikes were huge, but remained hidden for a long time due to metrics resolution. But eventually it got bad enough that clients ended up not getting responses.

rgbrenner 4y ago
There are circumstances where that’s the right strategy. For example, GitHub may be using it to ensure two requests for two different files in a repo receive the same version of the repo. Not saying they’re doing that.. just explaining the cache strategy. An explanation isn’t a recommendation for you to go out and apply it to everything. Source: founded and operated a cdn for 5 years of my life.
- _cenw 4y ago
  As long as you key the expiration to something, be that the client IP or the repository, you're probably fine. Having your entire customer base do their cache expiration request within the same small time span is not amazing though. You can already get consistent views of raw.github by looking up the HEAD commit and requesting your files from that commit directly, though.