Earlier quoted context omitted.
Using obviously better data structures the first time isn't premature optimization.
There was a reason for that field, but that reason never panned out.
Could you point to that reason?
Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
21–30 of 304 posts
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#22Earlier quoted context omitted.
I don't understand why you need training on your code base to design a cache format for read only vs rw workloads, but anyway yours is a comment about neglect, not the "evil" that would happen if you did that design
> I don't understand why you need training on your code base to design a cache format Because anyone willing to come in just to design your cache format is going to expect payment that is many multiples more than the engineers you already cannot afford? Long-term employees cost less, which brings them closer to being affordable, but you have to be able to keep them busy for long periods of time to realize that reduct…
You explained why it's beneficial for other workloads, but the original point was about this specific design
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#23One question the article doesn't answer is: why are they cacheing at all? If your cache is that big it isn't a cache. How much bigger is the dataset in question? There are 250 billion entries. Assuming 80/20, that implies 1.25 trillion records?
What's the speed of service/response time relative to the data source?
At that point it might be enough to replace your multiple caches with fewer in-RAM databases?
It's an interesting problem.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#24One question the article doesn't answer is: why are they cacheing at all? If your cache is that big it isn't a cache. How much bigger is the dataset in question? There are 250 billion entries. Assuming 80/20, that implies 1.25 trillion records? What's the speed of service/response time relative to the data source? At that point it might be enough to replace your multiple caches with fewer in-RAM databases? It's an in…
Maybe I'm misunderstanding, but this powers 1.1.1.1, it doesn't front an internal dataset. A cache miss hits a nameserver. Which is to say, the dataset is "every DNS record in the world"
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#25One question the article doesn't answer is: why are they cacheing at all? If your cache is that big it isn't a cache. How much bigger is the dataset in question? There are 250 billion entries. Assuming 80/20, that implies 1.25 trillion records? What's the speed of service/response time relative to the data source? At that point it might be enough to replace your multiple caches with fewer in-RAM databases? It's an in…
They’re adding the cache consumed across all of their servers. It’s not one giant deep cache.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#26I'll buys some spare RAM you now have. I only need 64GB.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#27This is why system programming still matters. Looks like they're missing the obvious optimisation of putting the record data right after the CacheEntry members instead of allocating memory separately though. But that might just be me as a C-programmer talking and not be all that easy in Rust.
System programming always matters. Things are cheap until they aren't one day.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#28Earlier quoted context omitted.
Engineers are expensive, especially good system engineers who are trained in your code base. Very possible that this just hadn't gotten to the top of the priority list.
I don't understand why you need training on your code base to design a cache format for read only vs rw workloads, but anyway yours is a comment about neglect, not the "evil" that would happen if you did that design
I see your point but disagree. Engineering is about constraints. Time, materials, labor, scope.
The “evil” of premature optimization is that it’s a misapplication of priority. If I have an acute medical problem that needs attention, it’s not the right time to talk about chloresterol and statins, get my broken leg set.
There’s always a tension between engineering management who needs to deliver a solution to the business and engineers who want to deliver a beautiful object.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#29One question the article doesn't answer is: why are they cacheing at all? If your cache is that big it isn't a cache. How much bigger is the dataset in question? There are 250 billion entries. Assuming 80/20, that implies 1.25 trillion records? What's the speed of service/response time relative to the data source? At that point it might be enough to replace your multiple caches with fewer in-RAM databases? It's an in…
You have to cache, cloudflare doesn't know all the records ahead of time, they have to do recursive lookups to the authoritative servers that own the records and that is only good for the period of the TTL of the record. There is no "global" DNS record database or something like that.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#30These seem like some fairly standard approaches for reducing memory usage. I can't help to think that the approach of joining several distinct list into a single one in some way undercuts Rust's safety guarantees.
If you previous had three distinct Vec objects, then Rust would guarantee that you can't index out of bounds. If you now put all those objects into a single Vec and rely on offsets, then you now open the door to indexing out of range of these sub-slices without any panics.
It's a minor point, and it doesn't really invalidate the optimization, but I'm surprised the article didn't mention it.