I've taught queuing theory before, and my favorite part is teaching about <i>cumulative flow diagrams</i>. I will preach it to anyone who will listen.<p>The CMF is the single best way to monitor your queues in your monitoring system, and most people don't do it. Almost everyone has a graph showing the current queue depth. They might even have alarms on it.<p>But if you see the queue depth going up, how do you know the cause? There are two possibilities: arrival rate increased quickly, or service rate dropped quickly.<p>But with a CMF, you can tell just by looking! One of the two sections will be getting fatter, telling you immediately where to look for the problem. If service rate is slowing, then you know to scale up your processing fleet, or look for a pathological case that is blocking processing. If the arrival rate is increasing, you can put in some backoff or load shedding, or just be happy about how busy your product is!<p>[0] <a href="https://en.wikipedia.org/wiki/Cumulative_flow_diagram" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Cumulative_flow_diagram</a>
I enjoy knowing a little bit of queue theory because it is a subject where not only can you gain an advantage in many areas but few people will be able to figure out why. In many cases that lack of figuring will continue even if the trick is explained.<p>Nearly any queuing system can be considered as an M/M/1 queue (in the same way as a linear model fits everything in practice). M/M/1 queues compresses a huge number of observations down into a 2 parameter model. So being able to see that some situation is an M/M/1 queue lets you store 2 numbers, shut down your brain and move on to other things. Compare that to the cognitive load of someone who has to start deriving outcomes with statistical formula!<p>Someone who doesn't know about queuing theory has 3 options, all wasteful:<p>1) Re-derive queue theory from first principles (this is the best option)<p>2) Specifically connect 2 observations that matter - ie, probably do a lot of guessing, experimentation and / or solving equations that don't generalise well.<p>3) Overprovision out of fear.<p>Therefore the advantage a queue theorist has - speaking competitively - is that it is <i>possible</i> to work out any queuing theory insight from first principles in a little bit of time. That gives the competition lots of opportunities to waste time and resources trying to work out things which are in fact well known outcomes of M/M/1 queues.
I would recommend Warteschlangensimulator to simulate processes involving queues. It's often faster to simulate things than to build mathematical models.<p><a href="https://a-herzog.github.io/Warteschlangensimulator/" rel="nofollow noreferrer">https://a-herzog.github.io/Warteschlangensimulator/</a>
Was anyone else unsatisfied with this article? Yeah sure, queueing theory is cool and fun and interesting but this article is really just a short list of used abbreviations and falls woefully short of genuinely interesting content.<p>You'll get more out of reading the Wikipedia article on queueing theory and on M/M/1 queues.
I came first across queuing theory in the context of managing software development processes. it looked at the flow of bug fixes and feature requests through the hands and brains of people out to users, and how task switches of those doing the work and task and context switches of teams and set-up times for steps like testing or doing a single change how all these timings and little queues at each step add up and define team productivity.<p>"The Principles of Product Development Flow" by Donald Reinertsen.<p>it made me realize queuing theory as a framework for "agile" or "lean" workflows, pull (kanban) or push (scrum), without ever using any of these buzzwords.
If you're interested in Queuing theory and systems then this book will help. The link only discusses trivial definitions, nothing special.
The book is by Prof. Mor Harchol-Balter of CMU. I referred this book extensively during my master's and it is still my favorite academic book. I can open it any day and start reading. The writing is very good. give it try if you're interested.
<a href="https://www.cs.cmu.edu/~harchol/PerformanceModeling/book.html" rel="nofollow noreferrer">https://www.cs.cmu.edu/~harchol/PerformanceModeling/book.htm...</a>
>> Little's law assumptions:<p>>> All measurement units are consistent.<p>>> Conservation of flow, meaning the average arrival rate equals the average departure rate.<p>Yeah, that checks out as the first and only two parameters most modern customer service behemoths are concerned about...<p>Reading this whole thing, my mind goes to how to wring optimal customer loyalty from a given queue, or how to relieve a queue in the way that would keep the most customers loyal. I guess that's why you shouldn't outsource.<p>Arguably, the theory of queues goes a long way toward explaining why the angriest people in a line are also the least coherent. It's funny to think about, in a Rowan Atkinson sort of way, that the more apoplectic you become while waiting the further you go back in the line. hah.
Murat had an interesting review on a seminal queuing theory book: <a href="http://muratbuffalo.blogspot.com/2023/09/review-performance-modeling-and-design.html" rel="nofollow noreferrer">http://muratbuffalo.blogspot.com/2023/09/review-performance-...</a>. It's surprising to me that these experts in distributed systems didn't find the book useful in practice.<p>I was wondering if there are other similar books that are as comprehensive and deep while offering practical values as well.
I used the question, "is this a queue?" a fair bit in product and in engineering.<p>Question I have is, as an abstract object, what other things are there in that category? e.g. is this phenomenon governed by, a channel w/ information, a differential, an integral, a state machine, a fluid, - and are these objects at the same logical level of abstraction as a queue?
This is well timed - I was just wondering the other day: could you scale an app to infinity with just a distributed queue and a distributed transactional data store?<p>From my experience at big tech - I’m starting to become convinced but need to investigate more.
If you like this stuff, play video games, and <i>somehow</i> haven't heard of Factorio, kiss your next few weeks goodbye!<p><a href="https://store.steampowered.com/app/427520/Factorio/" rel="nofollow noreferrer">https://store.steampowered.com/app/427520/Factorio/</a>
This book was a great exercise in understanding some of these concepts: <a href="https://www.oreilly.com/library/view/feedback-control-for/9781449362638/" rel="nofollow noreferrer">https://www.oreilly.com/library/view/feedback-control-for/97...</a>
Hmm. This page is 90% trivial definitions (names of concepts), Little's Law and a bunch of references? Knowing definitions without knowing what conclusions you can draw is not going to help your software development. It will, perhaps, help you sound smart(er) at dinner, though.
Not to be too snarky, but it kinda feels like an Airtag might have helped here ...<p>The total U.S. military budget for fiscal year 2022 was approximately $778 billion. I'm genuinely surprised that the US Air force needs our help finding ANYTHING.