Napkin Math 2: Applying It to Computers

In this post, I will be explaining the technique of estimating performance from first principles. It’s based heavily on the following talk: https://www.youtube.com/watch?v=IxkSlnrRFqc.

To recap, the purpose of napkin math is to provide a quick approximation to within an order of magnitude of the real answer, for the purposes of quickly testing the feasibility of the design of a system. Last time, we talked about Fermi estimation, which is (according to my definition) just napkin math where you’re primarily multiplying, and isn’t necessarily focus on computers.

But for our purposes, the goal has always been to eventually estimate the performance of computer systems. Take, for example, the following problem, also presented within the talk:

• There is a local client, written in Rust (take this to mean, no performance issues), talking to a Redis instance on the same machine.
• The Rust client is repeatedly measuring the latency of the GET operation, transferring an 8 byte payload each time.
• How long can we expect this to take?

I had memorized some base rates / did some googling, before arriving at my answer. If you don’t have the base rates off the top of your head, I encourage you to do the same. Here was my line of reasoning:

• We may assume no performance issues with the client
• 8 bytes is a trivially small payload, meaning we can ignore the data throughput speed here, and focus solely on latency
• Redis is an in-memory database
• Memory access is on the order of 100 ns.
• How does Redis communicate with the client? Is it a separate process?
• (Googles)
• Redis is a separate process. Therefore it must rely on ipc.
• What is the latency of IPC?
• (ChatGPTs)
• Okay, unix domain sockets are 1-10 us, while tcp/udp loobpack is 10-100 us.

At this point, I waited for the speaker’s multiple choice options. My thought was that it would be dominated by the ipc latency, since reading from memory was on the order of 100 ns, and ipc is a higher order of magnitude here. Post-hoc, I could additionally justify this choice by noting that Redis’s GET operation is O(1). The options:

• 10 ms
• 1 ms
• 100 us
• 10 us
• 1 us
• < 1 us

I ended up picking 10us, because I wasn’t sure if it would use unix domain sockets or tcp/udp loopback as the transport. But the answer was 25 us, so I basically picked the correct order of magnitude.

If we didn’t know the speed of memory access and IPC, it would have been much much more difficult to arrive at the correct answer. Therefore, it’s essential that we know as many of these reference points for computers that we can manage, so that we can solve these types of problems. It won’t get us the whole way though; we also needed some qualitative understanding of Redis and its implementation in order to arrive at the correct value. This is why it’s important to also read blog posts and understand the larger systems design ecosystem.

So let’s learn some reference points.

Whoa! That’s a lot. I don’t know about you, but I don’t really feel like memorizing this table. It’s a lot of values that don’t really mean much to me right now. We can get around this by learning the table incrementally – we do a practice problem, looking up the numbers as we need them, and then we add them to our Anki deck. We review our Anki deck every day, and hopefully we have it in our heads the next time we see a similar problem.

My next step in my systems design journey is to in fact go through the problems accompanying sirupsen’s talk, where problem n can be found at https://sirupsen.com/napkin/problem-{n}. I highly encourage you to watch it, and then go through these problems yourself. But that’s all I have to say about systems design for now.