Why I didn’t include queueing math in my book.

It’s been wondered about why I chose not to include any real amount of material in my book about the mathematical topics related to capacity planning, like queueing theory.

There are already many other excellent books that dig into the math behind Little’s Law, M/M/1 queues, and Poisson arrival processes. These concepts do indeed detail the behavior of capacity models, and at any given point in the lifetime of a web request, describe what the hell is going on. The best part about that math is that it can be applied to almost any computer system responding to requests, without regard to hardware configurations, operating system settings, or really any details about the application(s) you’re trying to model.

Requests come in, they get processed, might get tossed around within the back-end architecture, and then get spit back out as a response. Great! The math can model that.

But I didn’t cover those queuing fundamentals in my book for a bunch of reasons:

  1. Other books spend a good deal of ink going over it. I didn’t write a book to replace any of Neil Gunther’s or Daniel Menasce’s publications. I wrote a book meant to be useful for developers and operations people working on growing websites like Flickr. Not banks. Not mainframe applications. Not HPC clusters. Websites.
  2. When it comes to sizing infrastructure, I don’t like spending a lot of time on modeling and simulation, where that math has been historically used. Why? Because there are too many variables (and changes in those variables) in both the application and usage of the application to warrant any time developing a model. By the time I could have a model built that I had any confidence in, it wouldn’t be accurate enough to be worth anything. Instead, I wanted to focus on the fundamentals of recording, observing, and correlating both system and business metrics. The part where you tie systems statistics to business metrics (“What does 50% CPU actually do for my business?”) is a spot that I found lacking, and I believe that context has to be there in order to get the larger picture of your capacity.
  3. There was already enough material to cover about forecasting, metrics collection, and deployment.

Don’t get me wrong, the math is interesting. Hell, I spent almost 5 years of my career building models and simulations of nonlinear structural dynamics (vehicle crashworthiness research). But I didn’t see the need to have that material in my book.

I like making things go! At the moment, I am Etsy's CTO and I just recently finished my master's degree in Human Factors and Systems Safety at Lund University.

2 Comments

  1. Domas Mituzas   •  

    “overload=bad”. why would anyone need math for that? 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *