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

281–290 of 304 posts

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

#281

Post by Retric »

mtrovo wrote: post #243
Retric wrote: post #234

Earlier quoted context omitted.

In my experience optimizations actually preformed tend to have ridiculously high ROI because they are so rarely prioritized. Better performance = saving money + better user experience.

Depends on how you measure your ROI and how it could be different from how your company measure their ROI. The problem with optimizations is that you are competing in prioritization with other features. Reducing the baseline cost always has a limit of zero, while the upside from new features is infinite according to your leadership and investors, so it is very hard to argue against. In general it's challenging to con…

You’re assuming performance has zero impact on customer retention, spending, etc which is demonstrably false. Further future costs aren’t bound by the current customer base or fiscal quarter.

Insufficiently optimized code kills companies in highly competitive markets.

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

#282

Post by otterley »

Retric wrote: post #281
mtrovo wrote: post #243

Earlier quoted context omitted.

Depends on how you measure your ROI and how it could be different from how your company measure their ROI. The problem with optimizations is that you are competing in prioritization with other features. Reducing the baseline cost always has a limit of zero, while the upside from new features is infinite according to your leadership and investors, so it is very hard to argue against. In general it's challenging to con…

You’re assuming performance has zero impact on customer retention, spending, etc which is demonstrably false. Further future costs aren’t bound by the current customer base or fiscal quarter. Insufficiently optimized code kills companies in highly competitive markets.

Nobody’s assuming that. A well-functioning business compares opportunity costs with all those considerations in mind.

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

#283

Post by otterley »

megous wrote: post #254
otterley wrote: post #196

Earlier quoted context omitted.

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.

Nobody’s assuming that. A well-functioning business compares opportunity costs with all those considerations in mind.

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

#284

Post by deathanatos »

jcgl wrote: post #238
deathanatos wrote: post #185

Earlier quoted context omitted.

Dumb captive portals, which do still exist in some places, usually do MitM attacks on the connection, so you need some http(no-s) site that you can abuse as "yeah, this can get attacked by the WiFi" to then answer the portal. The right way is that there's DHCP option for the network to signal "I have a captive portal", that's been standardized for over a decade. … or … IDK … just stop shoving ads down people's throat…

I’ve never even heard of the DHCP option for this. How widely adopted is it? It’s surprising to hear it called “the right way” when it wouldn’t work for a single-stack IPv6 (or IPv6-mostly, probably) network.

DHCP works over IPv6, but there's also a corresponding RA option, too, if your v6-only network doesn't use DHCP.

https://www.rfc-editor.org/info/rfc8910/ is, I think, the latest version of the standard.

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

#285

Post by kevincox »

rfgplk wrote: post #51

Frankly weird that they were resorting to high level containers for this in the first place. Also, this line struck me as odd > Big Pineapple uses jemalloc, an allocator designed for multithreaded, allocation-heavy workloads. jemalloc multithreaded performance is actually poor(ish) compared to other modern allocators, which makes it a weird choice. But even weirder is why they're even using an allocator in the first…

It sounds like you are just writing your own allocator? That sounds great, but why is it going to be better than jemalloc?

There are many reasons a specialized allocator can be better, but just saying "write your own" doesn't really add much value to the discussion.

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

#286

Post by aperture147 »

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 the right way to deliver software.

It's only right if you are not the one who pay the bills.

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

#287

Post by fc417fc802 »

robotresearcher wrote: post #276
fc417fc802 wrote: post #203

Earlier quoted context omitted.

That's like refusing to use a fridge, insisting on letting your produce gradually spoil on the counter because "all harvested produce is in a state of decay anyway".

No, it's using a fridge in the understanding of the fundamental limitations of fridges. You asked ‘why would I want to use a service that serves stale data’. The answer is you don’t want to. But if you have a distributed system your only choices are about the nature of the possible staleness, since global instantaneous consistency is known to be impossible due to fundamental features of the universe.

In that case you're (intentionally?) misinterpreting what I originally said. The person I replied to was metaphorically suggesting turning the temperature dial on the fridge way up and I metaphorically asked why I would want to eat at his house if he's going to be serving me spoiled food.

My original question could also be described as asking why I would choose to shop at a grocer where items on the shelf are routinely far past the printed expiry date. That's perhaps a more direct analogy.

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

#288

Post by hinkley »

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.

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

I do a lot of tuning work that others either can't be arsed to do, or more often are scared shitless of touching (learned helplessness). I tend to work on things that have to go right the first time in general, but I firmly believe that I learned that skill doing optimization work early in my career, not the other way around. Through a series of unfortunate events, my first specialization was performance, before I got good enough at anything else for people to listen to me.

Ultimately, the single thing that fucks up performance work, far and above any other concerns or sources, is that the vast majority of developers want to skip from Make it Work to Make it Fast without going through Make it Right. Then they have to use dodgy 'optimization' tricks that embrittle the entire thing, destabilize production and make every new feature feel like walking a minefield.

So what happens is that when someone who actually knows what the fuck they are doing comes along and wants to build a superhighway, they find the route littered with abandoned 'vehicles' that have sunk into the mud up to their door handles and left to cement in place. Clearing the proverbial route becomes a bigger technical challenge than building the road. And so you'll find that your peers have a bunch of ideas about what needs to be done but none of the stomach to do any of it.

Which is why I say "stubbornness" is the most important tool in my performance toolbox, far above cunning.

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

#289

Post by esseph »

AlotOfReading wrote: post #279
esseph wrote: post #257

Earlier quoted context omitted.

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.

I picked the convention center as city center (union station would also be a reasonable choice) and I was only able to find 2 improved lots under $300k. Notably, neither is quite 3+ acres or within 20 minutes of the things you listed, and both are on septic. And this is in a metro where home prices are 36% below national median. [0] https://www.realtor.com/realestateandhomes-detail/3711-N-67t... [1] https://www.realt…

First if you us the convention center, you place the housing center off of where most of the housing actually is. Maybe 40% is in Kansas, with another 60% in the metro being on the Missouri side, roughly. The population density of the metro drags further south though if you look at it on a heatmap.

That said, look around:

https://www.zillow.com/kansas-city-mo/?category=SEMANTIC&sea...

Between $175k and $350k center on KCMO alone there are over 760 results.

Note: your first link https://www.realtor.com/realestateandhomes-detail/3711-N-67t... is 23 minutes from the WW I museum.

Note 2: Your second link is way out in Independence, MO but is still only 29 minutes away from the WW I museum.

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

#290

Post by hinkley »

vanviegen wrote: post #76
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.

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

This is perhaps the hardest nut to crack.

We give perverse incentives to the marketing department to bring us the most customers they can, instead of the most appropriate customers.

Someone told me at my second lead position that they had landed a top-tier customer for our demo-ware and the first words out of my mouth were, "FUCK ME". Not the response they were expecting, but then that guy never did end up understanding me the entire time we worked together. My bosses did though.

When your system is new you're a loss leader for all of your customers. Every dollar they bring in costs you two, possibly more. You have to get to positive MRR before the venture capital runs out, and over a long enough time horizon, you will go for a new round and find out that a recession is about to start and the VC guys getting cagey is the first clue it's coming.

Meanwhile if you spend all of your time and energy on reducing costs instead of increasing revenue, then your competitors catch up with you. Particularly if their funding rounds are half a cycle off from yours - one of you will be the last one to have gotten a cash infusion before the money dried up.

Most recently I worked at a place that didn't understand my calls for sobriety until it was too late. So I got put in charge of a rear-guard action that was too little too late, and our customers all fled to much cheaper competitors who could do 80% of what we could for half the price. I learned some good stuff, but the company got bought by a competitor who scrapped those systems.

Post reply on HN