New Year's resolution: Read "Systems Performance" by Brendan Gregg
04 Jan 2023I have 15 books on various aspects of Software Engineering on my “want-to-read” bookshelf. The biggest one of them, by far, is “Systems Performance” by Brendan Gregg. I bought this book after reading “Database Reliability Engineering”. It was referenced there and seemed like the kind of book that could help me improve my lower-level technical knowledge. For example, it has a chapter on Operating Systems and the learning goals for that chapter include “understand the role of the kernel and the system calls” and “gain a working knowledge of kernel internals.” These are the kind of things I know close to nothing about.
However, at 800 pages in length, the book is an intimidating read. So, I decided to make it my one and only New Year’s resolution to read this book. I’m writing a blog post now to kick it off and also plan to reflect next December on how it went. The only thing left to do now is to decide how ambitious the goal should be. My instinct is to say “half of the book” as I imagine it to be a bit dry and difficult read. However, when considering this I remembered a team-building exercise we had at work.
The team-building exercise was led by our HR partner. The task was to move a ball between team members as fast as possible, in such a way that it would touch both palms of each player. The catch was that we had to first estimate how fast we would be able to do it. We would be evaluated on whether we made it at that time or not. My initial instinct was to say “60 seconds,” as it would be the kind of time interval where could do it even if we dropped the ball a few times. However, the best actual time was something under 10 seconds, maybe even close to 6. After that, we had a reflection session where I got to discuss my need for “safe” estimates versus more challenging ones.
I see this New Year’s resolution as a way to challenge that need. Even though I’m more comfortable with a less ambitious goal, I believe it is possible to read the entire book in a year. When I say “read’’ I mean the way in which I read technical books. It includes highlighting and writing down the things that seemed interesting to me. Here are some statistics on how long it took me to read other of the technical books this way:
| Title | No. of pages | Reading duration (months) |
|---|---|---|
| Database Reliability Engineering | 294 | 6 |
| Fundamentals of Software Architecture | 432 | 3 |
| Kubernetes: Up and Running | 290 | 1.5 |
| High Performance Browser Networking | 400 | 2 |
Looking at these numbers 800 pages a year shouldn’t be a problem. The only reading experience that says otherwise was with “Database Reliability Engineering”. But I was reading it through spring and summer which is when I usually prioritize outdoorsy leasure over a bookish one. If the book will turn out to be too dry for me, there was a really helpful review on Goodreads:
“<…> I recommend reading the first few sections of each chapter, which typically have a nice introduction to the architecture of the CPU, memory, etc. They are also full of handy tables, such as typical, real-world latencies and typical performance trade-offs to consider (e.g. cpu vs memory, small vs large record sizes). The remainder of each chapter is a deep-dive into specific performance tools you can use, which is handy as a reference, but does not make for interesting reading otherwise, as there is no way you can retain so much detailed info <…>.”
See you in a year where we will find out if I ended up following this advice or reading the entire book!