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

251–260 of 304 posts

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

#251

Post by saidnooneever »

lpapez wrote: post #68

This is the right way to deliver software. Produce working product first, validate the idea, stabilize the business, start generating profit, and then you can start optimizing your costs. In fact optimization is by far the easiest part of the process because there are many system programming experts on this HN thread who consider these optimizations to be trivial.

right or wrong, good or bad are all taste.

from a business perspective, this might be considered the only way, but it is not. at large volume scale it becomes more, but often large scale is lacking optimisations in the first place.

its not wrong in my eyes, but definitely not the only path to take.

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

#252

Post by ww520 »

Tuna-Fish wrote: post #242
ww520 wrote: post #156

Not sure what they use to hold the cache key and entry. If a hashmap is used, then a radix tree (adaptive radix tree) would be better in saving memory space. Most of content of the qname field of the CacheKey is hostname, like www.site.com. The reverse version com.site.www fits nicely in navigation path of a radix tree. The common prefixes like "com." are shared and compressed in the parent nodes of the tree. Even a…

At this scale, moving from one pointer chase to multiple is almost certainly a huge loss, even if radix tree would save a lot of memory.

Unless the keys are completely random, compressed keys shorten the tree height and cause fewer pointer jumps. Hostnames are highly compressible. Plus the root and the upper levels of the tree are always hot, most likely in L1/L2/L3 all the times. OTOH collisions in hash table cause pointer chase as well.

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

#253

Post by jordiburgos »

grep_it wrote: post #192

This reminds me how you can save a bunch of bytes just by making sure your structs are aligned. In go for example: type Wasteful struct { a int16 b int c byte } type Aligned struct { b int a int16 c byte } Will have sizes of 24bytes and 16bytes (on a 64bit system). Same data 8bytes more. If you are storing millions of those objects, then it adds up.

Why this is not done automatically by the compiler? That seems something quite easy to calculate to me.

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

#254

Post by megous »

otterley wrote: post #196
vanviegen wrote: post #76

Earlier quoted context omitted.

Or optimize a bit earlier and prevent having to scale out to a bazillion systems.

Remember that everything has an opportunity cost. Running a lot of servers might cost $10 million annually, but if the product team had to choose between a project that would recoup $5 million of that vs. an opportunity to earn $50 million ARR for the same amount of work, the logical answer would be obvious.

You're assuming faster/more resource efficient software would result in the same ARR as the laggy slow one, but that's not a given.

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

#255

Post by gbin »

lpapez wrote: post #68

This is the right way to deliver software. Produce working product first, validate the idea, stabilize the business, start generating profit, and then you can start optimizing your costs. In fact optimization is by far the easiest part of the process because there are many system programming experts on this HN thread who consider these optimizations to be trivial.

This is true if you can scale out (ie you can add resources to your system). But for a robot for example, just adding a GPU can just flop your product completely: you need more battery, more weight, suddenly your unit economics is out of the window... Your next hardware iteration will be very slow to come and very expensive. So here, you better not have a system wasting too much resources pretty early on after the prototype phase.

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

#256

Post by esseph »

anon48293 wrote: post #213
esseph wrote: post #199

Earlier quoted context omitted.

> is it possible to buy a reasonably nice home located in a reasonably nice amerikkkan city… for $300k in 2026? What does "city" mean to you? For some, it's 500 people, or 5,000. For some, it's 5 million. Define that first. The US is a big place, and I know people that don't live within 50 miles of another human. Otherwise: https://www.zillow.com/homedetails/424-Olive-St-Kansas-City-... 4 bed, 3 bath, 1,580 sq ft, be…

That’s 350, which you can’t buy for 300..

These are midrange. Most of the homes in those areas are around $225k.

You'd be surprised how much house and land you can get for that price.

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

#257

Post by esseph »

AlotOfReading wrote: post #178
esseph wrote: post #150

Earlier quoted context omitted.

That would buy you thousands of square feet and often several acres within 20 minute drive to a lot of US city downtown areas.

Can you ground the discussion by mentioning what you think these cities are? Taking Columbus, OH as the most average of American cities and a 20m isochrone map from city center, there are currently 0 parcels for sale with 3+ ("several") acres under $300k. There are a few within 30m drive, one of which even has a possibly habitable structure. The rest are bare agricultural land you'd need additional investment to actu…

I'm just looking at Kansas City as an example right now.

Tons in the $200s btw, and this is in the city less than 20 minutes from the Nelson-Atkins Museum, WW I museum, the river, farmers market, KC Chiefs / Royals / Sporting KC / KC Current teams, parks, schools, newly rebuilt international airport, etc.

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

#258

Post by JeromeLon »

jordiburgos wrote: post #253
grep_it wrote: post #192

This reminds me how you can save a bunch of bytes just by making sure your structs are aligned. In go for example: type Wasteful struct { a int16 b int c byte } type Aligned struct { b int a int16 c byte } Will have sizes of 24bytes and 16bytes (on a 64bit system). Same data 8bytes more. If you are storing millions of those objects, then it adds up.

Why this is not done automatically by the compiler? That seems something quite easy to calculate to me.

There is no way in C to express that you don't care about the orde. When you express a struct in C, you list what you want in the struct and (sometimes without wanting it) exactly in what order you want it.

Interestingly, there is also no way to write a loop on i for all the values between 0 and 99 without specifying the order. Luckily, in this case, the compiler is allowed to prove that the order has no impact (because it's local), and to decide that it will scan the values in a different order for optimisation purposes.

So the compiler could do it on a structure as well, as soon as it's able to prove that the structure is not exposed in any way to any code that it doesn't control, but that's much more difficult than proving that variable i is not visible outside of a tight loop.

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

#259

Post by phoghed »

PeterStuer wrote: post #225
jacquesm wrote: post #165

Earlier quoted context omitted.

It means you are paying for a support contract. Whether you actually have one time will tell.

Only seasoned engineers will understand you are not joking.

Sorry, the very simple thing you’re trying to do is too complex and non-standard for our support team to handle. We’ll gladly sell you a consultant for $400/hr. He’ll work on modifying our system, and then we’ll sell those modifications to everyone else.

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

#260

Post by chii »

lpapez wrote: post #68

This is the right way to deliver software. Produce working product first, validate the idea, stabilize the business, start generating profit, and then you can start optimizing your costs. In fact optimization is by far the easiest part of the process because there are many system programming experts on this HN thread who consider these optimizations to be trivial.

> start generating profit, and then you can start optimizing your costs.

this assumes you can generate profit before you can get optimized - what if profit generation is only possible with optimized software? A lot of online MMO-style games tend to require such optimizations as they scale into the size required to generate profit.

Or, in the current era of ai, the cost of the capital investment is far exceeding the ability to generate profit off it. The optimization in how the resources gets used will be needed to cut the costs down, and allow increase in the scale of usage for the same hardware. That's where profits would lay.

Of course, in order to achieve any of this, you'd need the runway to survive until such times. A small scale operator won't have this runway, and so die before they can accomplish anything profitable (or get big by begging for investor money to grow large - as we've seen in the past 20 years of tech).

Post reply on HN