From 4834c69a5fdb1eab0e06d492eae214d4532bff1d Mon Sep 17 00:00:00 2001 From: Mike Spreitzer Date: Mon, 15 Aug 2022 00:14:18 -0400 Subject: [PATCH] Removed usage of "width", _defined_ "seat" --- .../concepts/cluster-administration/flow-control.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index f2b0d18fed..1b76168998 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -96,13 +96,15 @@ Pods. This means that an ill-behaved Pod that floods the API server with requests cannot prevent leader election or actions by the built-in controllers from succeeding. -### Request Width +### Seats Occupied by a Request The above description of concurrency management is the baseline story. -In it, all requests have equal "width": each takes up one _unit of -concurrency_, which we call a "seat" because this is similar to how -each passenger takes up one of the fixed supply of seats on a train or -aircraft. +In it, requests have different durations but are counted equally at +any given moment when comparing against a priority level's concurrency +limit. In the baseline story, each request occupies one unit of +concurrency. The word "seat" is used to mean one unit of concurrency, +inspired by the way each passenger on a train or aircraft takes up one +of the fixed supply of seats. But some requests take up more than one seat. Some of these are **list** requests that the server estimates will return a large number of