31–40 of 145 posts
Earlier quoted context omitted.
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.
Is that really common? That sounds like a recipe for disaster.
What level of service should we expect from github? Many of its services are free, can we ask for more when not paying?
I'm actually more amazed GitHub will give you a response in the 2xx range at all for these use-cases.
This seems reasonable to me. Caches should last longer; if you want to be sure of you get the latest version, rename the file. a good trick is to include the hash of the file in the name to get content-addressing à la IPFS.
Rename the file to get what you want, am I the only one finding that a very strange approach?
GitHub caching can be a pain. It's been for example impossible to make files completely disappear from an open source repo without deleting the repo or contacting their support.
https://github.blog/2022-09-13-scaling-gits-garbage-collecti...
https://github.com/orgs/community/discussions/46691#discussi...
This seems reasonable to me. Caches should last longer; if you want to be sure of you get the latest version, rename the file. a good trick is to include the hash of the file in the name to get content-addressing à la IPFS.
Reading the comment threads on GitHub, some files get a TTL of 300, some get a TTL of 86400. The "why" is certainly an interesting question.
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.
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.
(Well, if we believe the statement "github engineer here". Of course every clown could write that, too)