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

91–100 of 306 posts

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

#91

Post by lpapez »

casey2 wrote: post #82
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 reasoning assumes you have access to infinite runway. You don't.

Exactly, and you need to start turning a profit before the end of that runway. Even if that means running code that is suboptimal.

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

#92

Post by steve_adams_86 »

bcrosby95 wrote: post #86
vanviegen wrote: post #76

Earlier quoted context omitted.

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

The way I usually prevent having to scale out to a bazillion systems is never getting more than 10 users.

I wonder why Cloudflare didn’t think of this

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

#93

Post by afdbcreid »

f311a wrote: post #70
irdc wrote: post #4

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

Unfortunately, Rust is not a good choice for this kind of tricks. This is where Zig shines. In Rust, you can’t even use proper arenas, which can help a ton with allocations. Cloudflare started to pick Zig recently, for projects, that have memory constraints.

> In Rust, you can’t even use proper arenas

You definitely can and this is done a lot. What you might mean is that you can't use standard library's collections with them (this is getting stabilized soon!) and have to use third-party, but that is a different thing than "can't use arenas".

> Rust is not a good choice for this kind of tricks.

Rust can do those tricks, but it's true that it is hard than in C or Zig. That said there are often crates to help.

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

#94

Post by afdbcreid »

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

Not really. You just need to make the underlying fields private and provide methods to get slices to the data you need.

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

#95

Post by rexpop »

casey2 wrote: post #82
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 reasoning assumes you have access to infinite runway. You don't.

Every startup is one bet in a Martingale strategy played by the class of people who remain solvent when you bust.

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

#96

Post by comprev »

MayeulC wrote: post #52
bhouston wrote: post #32

I've run into issues with using public wifi when I override my MacBook's DNS server to 1.1.1.1 or 8.8.8.8. I believe this is because captive portals require custom resolution of the name captive.apple.com. And external DNS servers will not resolve that correctly to the local gateway's authorization page.

AFAIK (at least it worked like that some 10 years ago) the captive portal just intercepts the HTTP page load and inserts its own content (most often a 302). So it just has to be a http web page. Firefox uses http://detectportal.firefox.com/canonical.html Relevant support page, though light in details: https://support.mozilla.org/en-US/kb/captive-portal Edit: ah, yes, DNS can be hijacked too (requires intercepting out…

I've had reliable success by using http://neverssl.com to force a basic HTTP connection for kickstarting a public WiFi portal login, although I have to disable NextDNS (iOS) too.

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

#97

Post by ramon156 »

lpapez wrote: post #91
casey2 wrote: post #82

Earlier quoted context omitted.

This reasoning assumes you have access to infinite runway. You don't.

Exactly, and you need to start turning a profit before the end of that runway. Even if that means running code that is suboptimal.

i suppose you could say the same about buying a house. just make that initial 300.000 and from there on out its easy. everything looks better on paper

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

#98

Post by perching_aix »

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…

> Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.

Genuine question, is software performance really linear like that, that one can and should only fight the tightest bottleneck, one workload at a time? Never really sounded right.

It also sounds like the typical sleight of hand where the difficult bit is simply laundered a layer up, in this case the choice of what workload one investigates.

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

#100

Post by kevin_thibedeau »

steve_adams_86 wrote: post #92
bcrosby95 wrote: post #86

Earlier quoted context omitted.

The way I usually prevent having to scale out to a bazillion systems is never getting more than 10 users.

I wonder why Cloudflare didn’t think of this

This is Broadcom's business model
Post reply on HN