Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

blog.cloudflare.com

Post reply on HN
Print view View original

41–50 of 305 posts

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#41

Post by toast0 »

mannyv wrote: post #23

One 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…

It's a recursive resolver. The global DNS dataset is not something you could collect to serve directly vs caching from observations.

The data source is authoritative name servers operated by third parties, some of which are slow on their own, some of which are behind slow or lossy networks. Origin response times vary between probably 1 ms and 2 seconds +/- origins that never respond.

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#42

Post by eviks »

suriyaG wrote: post #20
eviks wrote: post #11

Earlier quoted context omitted.

It's also often that you can avoid all those future migration/fallback risks and pains if you invest a little bit of design thinking upfront. So how would you decide which path to take in situations like this?

It only looks super obvious in hindsight and the well explained blog post. when a team of 5 is tasked with getting a completely new DNS up at the scale and integrate well with cloudflare. if you spend cycles on nitty gritty opinions like this time to market goes out further and further out. some napkin math, 130 gen13 servers cost "only" ~$2.6M. relative to the importance of the 1.1.1.1 and the market at the time. th…

This one also looks pretty obvious "in foresight" (using the same tools that existed back then. Maybe owner dedupe might be less obvious and require a bit of knowledge and probing into actual data, but for rw vs ro you are fine knowing nothing?) and you forgot the napkin math re. how much your precious "time to market" would have been delayed by.

It's also not nothing, otherwise it would never be optimized away now, but left as is. After all, wasting time on optimization delays "time to market" for other useful features.

I also don't get the reference to YouTube, it's a very successful product, how was it butchered by good system design???

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#43

Post by ratorx »

vinkelhake wrote: post #30

These 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 do…

I think it’s more of a time vs code tradeoff, if done properly.

For example in the Vec case, you could theoretically build an alternative which encodes the “three sections” property internally, and ensures correctness at construction time for the pointers. Not as completely safe as a Vec, but you can still get similar benefits for the “business logic”.

But I agree, just having a custom structure that does not provide a safe wrapper around this would be sacrificing standard guarantees.

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#44

Post by eviks »

r3trohack3r wrote: post #37
eviks wrote: post #2

> Once we store a DNS response in the cache, however, we never modify it again. The capacity field serves no purpose, but still costs 8 bytes per Vec Were there no design discussions/reviews when the system was setup to catch trivial things like this?

Rob Pikes 5 Rules of Programming: Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. Rule 3. Fancy algorithms are slow when n is…

> Data structures, not algorithms, are central to programming

So you agree that they should've designed the system to use the appropriate data structure from the beginning?

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#45

Post by pbhjpbhj »

seiferteric wrote: post #29
mannyv wrote: post #23

One 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.

>that is only good for the period of the TTL of the record.

Not really, TTLs are often short, but IPs might not change for years.

You can probably generate your own TTL, at scale, and avoid many DNS requests.

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#46

Post by ecnahc515 »

auspiv wrote: post #36
bastawhiz wrote: post #24

Earlier quoted context omitted.

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"

I think the question is probably more along the lines of - why not do a database with 100 TB of storage/records instead of a cache? tomato / tomato.. especially with smart caching in front of database. 100TB of flash is a good bit cheaper than 100TB of memory

Because it would be slower and have different scaling requirements than the ones they want.

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#47

Post by seiferteric »

pbhjpbhj wrote: post #45
seiferteric wrote: post #29

Earlier quoted context omitted.

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.

>that is only good for the period of the TTL of the record. Not really, TTLs are often short, but IPs might not change for years. You can probably generate your own TTL, at scale, and avoid many DNS requests.

then they would be breaking DNS at scale.

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#48

Post by ecnahc515 »

eviks wrote: post #44
r3trohack3r wrote: post #37

Earlier quoted context omitted.

Rob Pikes 5 Rules of Programming: Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. Rule 3. Fancy algorithms are slow when n is…

> Data structures, not algorithms, are central to programming So you agree that they should've designed the system to use the appropriate data structure from the beginning?

Notice rules are ordered. You don't optimize until you know you need it. They started with a data structure they though would be fine. Clearly it was fine since it worked and they decided it was later worth optimizing.
Post reply on HN