如何测量一个(传输网络)系统的容量

Little 定律就能反算系统容量，但我这篇文章要正着算。

假想一个理发店场景。李大爷拥有一家占地 50 平米的理发店，经理到店里理发如果已经有经理在理发，就要拿个券等待，请问李大爷需要印多少等待券？

这是个系统容量问题，答案在 “方法 1：按理发店容纳的经理数” 和 “方法 2：李大爷 10 分钟最多理多少头” 之间。

• 方法 1：如果李大爷 10 分钟最多 10 个头，房屋能装 60 个经理，理完 60 个头就要 60 分钟，最后一位经理就要等待 60 分钟时间。
• 方法 2：不管李大爷 10 分钟最多理几个头，最多印 1 张券，无论何时到达的经理都只需要最多等几分几秒钟。

不管哪种方法，系统都是稳定的，采用方法 1，如果有经理觉得等待时间太久，他大概下次要么早点来，要么不会再来了，平均而言，李大爷的顾客会维持在一个稳定的量，取决于店里装多少经理，采用方法 2，几乎来了就能理，顾客也会维持在一个稳定的量，取决于李大爷 10 分钟理几个头。

人们倾向于方法 1，包括公立医院，银行，饭店在内，只要在营业，就会一直发号，这其实是一种错误的方法。

我先把方法 1 和方法 2 画个图：

说回自己行业，当需要做容量规划，或确定自己系统的容量时，很简单，不需要做基准测试，只需不断增加负载并观测时延变化，当时延开始明显增加时的负载就是系统的容量。实践中，就是采集一组数据，拟合，画图，看图说话。

结论是，要按照处理能力规划容量，而不是按照 buffer 能力规划容量。但很少有人真正理解这一点，下面我来建模分析一下，同时说明这也是 bbr 的操作点是最佳操作点的一个证明，然后给出一个简短说明，说一下为什么方法 1 不好，我仍然会用拥塞控制领域的 aimd 说方法 1。

设 f(x) 为系统能力函数，g(x) 为处理时间函数，x 为负载。一个最大能力恒定的处理系统可以表述为：

• $\text{当 }x=x_0\text{时，}f(x)\cdot g(x)=x_0$；

• $\text{当 }x<x_0\text{时，}f(x)\cdot g(x)<x_0\text{ , }f(x)\text{ 相对增长率大于 }g(x)\text{ 的相对增长率}$；

• $\text{当 }x>x_0\text{时，}f(x)\cdot g(x)>x_0\text{ , }f(x)\text{ 相对增长率小于 }g(x)\text{ 的相对增长率}$。

那么 x0 就是该系统的容量。

下面我来证明 “将负载维持在系统容量附近(统计偏差一丢丢)是最优的”。我用 $E(x)=\frac{f(x)}{g(x)}$ 表示效能，理由是李大爷希望在负载更小的等待中获得更大的能力。对 E(x) 求导：

$E^{\prime }(x)=\frac{f^{\prime }(x)\cdot g(x)-f(x)\cdot g^{\prime }(x)}{g^2(x)}$

接下来利用第 2，3 条件，使用相对于当前值的相对增长率是合理的，因为消去了量纲，获得了纯增长率，有

$\text{当 }x<x_0\text{ 时，}\frac{f^{\prime }(x)}{f(x)}>\frac{g^{\prime }(x)}{g(x)}$

于是有：

$f^{\prime }(x)\cdot g(x)-f(x)\cdot g^{\prime }(x)>0$

结论是：

• $\text{当 }x<x_0\text{时，}E(x)\text{ 是增函数}$；
• 同理，$\text{当 }x\le x_0\text{时，}E(x)\text{ 是减函数}$；
• $\text{当 }x=x_0\text{时，}E(x_0)\text{ 获得最大值}$。

这个也可以从 f(x) 和 g(x) 的图像中一眼看穿：

这同时也证明了 bbr 的操作点是最优的，该操作点就是 inflt = bdp，此处同时取到 maxbw 和 minrtt：

类似于李大爷最大的修头能力和经理最小的等待理头时间。

这个论述不仅仅适用于李大爷理发和传输协议拥塞控制，对服务器，cpu 性能调优也适用，我只是用我自己比较熟悉的领域来举例。

现在来对比一下文处所述方法 1，相比上面论述的方法 2 基于能力动态适应，方法 1 是静态的，它是基于静态 buffer 大小的。仍以 aimd 举例，一个 aimd 算法不需要测量任何能力和容量，只需要两个静态变量，一个是 buffer 大小，另一个是 β。

一旦 β 确定，时延和带宽利用率就很难两全其美。证明如下：设 W 为 cwnd，B 为恰好 100% 利用带宽时 buffer 的大小，先算一个的 B 和 β 的关系：

$\{\begin{array}{l}W=bdp+B\\ (1-\beta )W=bdp\end{array}$

联立上述方程组：

$B=\frac{\beta \cdot bdp}{1-\beta }$

如果 buffer > B，时延就会增加，如果 buffer < B，带宽利用率就会不足，但对于单流而言，无论 buffer 配置多大，大时延大带宽，小时延小带宽，什么都没有改变。

另一方面，如果减小 β，理论上可以配置更小乃至非常小的 buffer，锯齿也相应成为小小毛毛尖，但却造成了频繁丢包和重传，根据简单的 aimd 推算，丢包率 p 和 β 的关系如下(参见 bbr 好在哪里)：

$p=\frac{1}{\beta \cdot B^2(1-\frac{1}{2}\cdot \beta )}$

buffer 减小，p 增大，排队时延转嫁到了重传时延，什么都没有改变。因此可以看出，aimd 算法存在固有效率损失，它依赖的收敛信号恰恰是丢包，而丢包要引入重传时延，它永远也无法收敛到 x0。

以损定损，损之又损，我不明白为什么总有人拿 aimd 说极致优化。

那么到底多大的 buffer 合适呢？早期建议约定时端口出口带宽与 100ms 的乘积，这显然仅仅满足了可用性，完全谈不上效率。加上设备 “以料足为贵”，buffer 大小更是五花八门，因此 bufferbloat 固有且无法消除。这和商场餐饮店门口长长的等待叫号异曲同工。

不怪 buffer，也不怪算法，是 buffer 就会被塞满，因为无法统一无法同构，只要有一条流在 capacity-seeking，抖动就无可避免，这种事在 parking lot topology 更容易发生，几乎睁眼可见，我留到下一篇说。

总之，你知道如何测量系统容量了吗？值得一提的是，网络链路，bdp 容量的测量要难得多，这也是 bbr 在现网表现并不都优秀的原因，这也是 aimd 算法永远迈不过去的坎，下次说。

本文主要讲动态容量评估和静态容量评估，水随山势，山不转水转，然而但凡你能测量 bw 和 rtt，就不至于随波逐流，但不可否认的是，aimd 是好的，什么都不用做。

浙江温州皮鞋湿，下雨进水不会胖。