[Jensson]

> every system has exactly one bottleneck at any given point in time

What, no they don't. Does a straight glass have a bottleneck? No, most bottles have it, but not straight glasses, hence not every system has a bottleneck.

The same applies to IT systems, there the topology is much more complex so often can have many bottlenecks, or sometimes fewer etc.

> Riddle me this: how can a system perform faster than its single slowest component?

A perfectly optimized component can't be a bottleneck but can still be the slowest component, trying to optimize that further will not speed up the system at all.

Here we see that you will miss a lot of optimization opportunities since you think the slowest component is the bottleneck, and not looking further.

[llamaimperative]

I don't find the glass <> IT system analogy compelling (or even sensical) at all.

Describe to me how an IT system can produce results (e.g. tickets closed, if you wish) at a rate higher than the processing rate of the slowest component.

> A perfectly optimized component can't be a bottleneck but can still be the slowest component, trying to optimize that further will not speed up the system at all.

Correct -- but neither will optimizing anything else! That's the whole point!

[Jensson]

> Describe to me how an IT system can produce results (e.g. tickets closed, if you wish) at a rate higher than the processing rate of the slowest component.

It can't, but the slowest component can be perfectly optimized and thus not be a bottleneck. You would fail to find a real bottleneck in this case, since you are just looking for the slowest one, hence I have proven that your statement above was false, there are cases where the optimal strategy is not to just look at the slowest component.

If you have some other definition for bottleneck we can continue, but this "the slowest component" is not a good definition.

[llamaimperative]

No, what you've done is you've failed to find a way to improve the system's behavior further. If you have the slowest component and you can't make it faster, then congrats: you cannot make the system faster.

You cannot build cars faster than you can mine metal, nor faster than you can put stickers on the windows on their way out the factory. You are done optimizing.

[Jensson]

> If you have the slowest component and you can't make it faster, then congrats: you cannot make the system faster.

That isn't true, I can take the next slowest component and make that faster and now the system is faster.

[llamaimperative]

Lol, no! You cannot!

The system's behavior will not change, you will just have wasted money improving the next-slowest component for quite literally no benefit.

Machine A (10 units per hour) -> Machine B (20 units per hour) -> Machine C (15 units per hour) => Produces 10 units per hour

Machine A (10 units per hour) -> Machine B (20 units per hour) -> Machine C (20 units per hour) => Produces 10 units per hour

Machine A (10 units per hour) -> Machine B (25 units per hour) -> Machine C (20 units per hour) => Produces 10 units per hour

Machine A (10 units per hour) -> Machine B (30 units per hour) -> Machine C (20 units per hour) => Produces 10 units per hour

Machine A (10 units per hour) -> Machine B (30 units per hour) -> Machine C (100 units per hour) => Produces 10 units per hour

Machine A (10 units per hour) -> Machine B (10,000 units per hour) -> Machine C (10,000 units per hour) => Produces 10 units per hour

[Jensson]

That is only true for parallel executions, not serial ones. If a process requires executing many components serially (which happens a ton), then it isn't enough to just look at the slowest component.

Anyway, thanks, now we know that you only considered throughput in a factory like setting, there it is true. But your rule there isn't true for software systems in general, optimizing latency speeds and serial performance is extremely common in software.

Edit: Example:

Machine A takes 1 hour -> B 2 hours : System takes 3 hours.

Machine A takes 0.5 hour -> B 2 hours : System takes 2.5 hours, so faster even though we optimized the faster component.