Every Computer Performance Book: How to Avoid and Solve Performance Problems on The Computers You Work With

Bob Wescott (2013)
Review date: January 2014
Summary

The first chapter explains why the book is more usable than other performance books and gives some background on the author. The next chapter is the mandatory introduction and is used to divide the topic into four areas: performance monitoring, capacity planning, load testing, and modeling. These four major areas then get their own chapters.

Chapter three is the "theory" chapter. Its first half is dedicated to explaining terms like response time, utilization, service center, throughput, wait time, response time, and a bunch of laws, like Little's law, Utilization law, Service Demand Law, and Law of the Minimum. The basics of queuing theory are also treated there. This chapter also contains some "softer" material; it also covers the perils of giving preliminary (premature) results, "firefighting addiction" (being hooked on often fixing performance problems, but doing it superficially), and how to approach others to get help.

The next chapter is on performance monitoring. It starts by listing things that need to be known about a meter to make it useful.  Then it proceeds to data collection. It also contains a good and simple example of applying confidence intervals to sampled data to tell how likely all data in the sampled interval exhibits a certain property, like response time. It ends with tips on how to meter for different scenarios.

The fifth chapter is on capacity planning. First, the four numbers relevant to capacity planning are introduced: utilization, scaling factor, safety margin, and max utilization. Logically, ways to use these numbers follow. Then there's a section on planning for limits and it contains examples of resources the use of which needs to be planned. The chapter ends with a discussion on when to do capacity planning.

Chapter six is on designing and running load tests, and making sense of the results.

Chapter seven is on modelling. Its two major sections are on capacity models and simulation models, although it starts with a general discussion on modeling.

The last chapter is on presenting the results. It contains some tips that work well in pretty much any presentation, especially the "given by a consultant" kind. It also talks about the audience and stakeholders. It also gives some tips about presenting rather technical findings to the CEO and higher level executives.

Finally, there's an appendix that contains all of "Bob's Performance Rules", fifteen of them, which appear throughout the book and provide the author's wisdom and experience in a compressed form. In the appendix, they are supplemented with short discussions.

Opinion

I was really excited to read this book. Content-wise it's just at the fringes of my field. Everybody is affected by performance problems, and like many others, I've done my share of performance work by looking at meters provided by the OS or a profiler.

Often, I find myself complaining about books being on a too basic level, but this time I knew that the book was above mine; when reading it, I was nodding to myself and humming "that makes sense" (well, not literally, but in thought). Now, the catch was that the author made those statements based on years and years of experience, while I thought they made sense. This is usually an indication of me not knowing enough about the subject to be able to relate enough to the material.  Don't believe me? Try this level of abstraction: Bits come in and are processed in memory by the CPU, some waiting happens, bits get read or written locally, and bits go out. This is the author's way of describing how software works (in a specific context, to be fair). Still, I always smile when I see this.

Since I don't consider myself a complete beginner, I'd say that this, in a way, is an advanced book; it presumes that you know the basics, and gives you structure, useful advice, and some war stories to make you better.  So, that would be my first reflection, not a "performance for dummies" book.

My second reflection is that the author delivers on a promise made at the beginning of the book, where he states that it's to be timeless. It'll give generic advice, not bound to any particular software package, environment, or method. This turns out to be true. One could read this book in ten years, and its contents would still be valid (though they would elude performance dummies like me to some extent).

My third reflection is on readability. The chapters that make up the bulk of the book felt too big. Some of them covered a lot of ground, from technical basics to "people stuff". Cramming too much into a chapter without a mental break for the readers is demanding a lot from them. You can see this in my chapter summary, where I write: "This chapter is about this, but it also covers that, and ends with yet another thing". I think I understand the intention behind the division of the book, but I would absorb the material better if chapters three through seven were split pretty much right down the middle; every one of them. I think there are some very natural boundaries right in the middle of each of these chapters. That's just an opinion though. Other people may have different reading styles.

My final reflection is on learning. Personally, I've learnt a lot. For example that I don't know as much about performance work as I thought I did. Apart from that, this book really covers a lot of ground. To me, it seems somewhat superficial at times, but at an equal level of abstraction. To give a specific example: chapter 7 - the section on simulation models. I understand what problem them solve and why they are good, but if someone asked me to create one, I wouldn't know where to start. On the other hand, someone who has experience in this kind of modeling would probably find that section most helpful.

The chapters that contributed the most to my learning were the chapters on performance monitoring and load testing. Also, for those of us who don't do performance work for a living, the concise theory in chapter three contains enough material to help us get the terms right (and some more things that we might have lived without knowing).

My biggest a-ha was when reading the warning about response time getting shorter while the load is increased. This is an indication of things breaking and error handling routines omitting the main transaction path. I've seen this enough times to testify about the statement being true.

So, to make an Amazon style review:

This is a timeless book on performance. Its contents will be as applicable in a decade as they are today. The book covers a lot of ground and touches both the technical side of performance work and the social side, which is about getting help, cooperating with others, and presenting the results.

Personally, I think that it would benefit from splitting some chapters in half to make them more reading-friendly, but that probably depends on one's reading style, reading time, and experience in the field.

Those entirely new to performance-related work may want to get the basics first (from other sources), because even though this book covers the fundamentals to some extent, I think you benefit more from reading it if you can relate the material with your own experience.  

Who should read this book

Those who work with performance will find a practical book that covers many aspects of the field.




News

  • 2015-09-29

    It's been almost one and a half year since I reviwed a book! I've been too absorbed by Writing my own. Anyway, I'm back with Jeff Patton's relatively...
  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.