EP19：压力测试方法论：从单机到全球压测

在 YouTube 打开

上集回顾	EP18《录像与回放：给直播加上 VOD》
下集预告	EP20《PPCDN 为您带来 30%~50% 的带宽 & 成本 & 时延节约！》（全系列收官）

0. 本集目标

看完这一集，观众应该能做到三件事：

1. 怎么测单节点容量：同一套方法、同一个 standalone 节点规格，分别在 AWS 和 LightNode（马尼拉机房）压测，看懂为什么同样的机器规格会测出天差地别的结果。
2. 认清最大的约束是什么：CPU 和内存可以升级，出口带宽不能随意加大——这对自建的 standalone 节点如此，对平台自己的 Origin、Recorder 节点更是如此，网卡带宽直接决定了它们的扩容上限。
3. 看懂真实的压测方法和数据：阶梯式加压怎么做、每一档看什么指标、三份真实报告摆在一起能读出什么共同规律。

---

1. 怎么测单节点容量：同一套方法，两个机房

1.1 方法：阶梯式加压

测的是 standalone 节点（EP17 讲过：单实例同时接推流、给观众播放，不转发、不回源）。工具是 whep-loadgen——基于 pion/webrtc 的自研客户端，对节点的 WHEP 端点建立真实的 PeerConnection，完整走一遍 SDP/ICE/DTLS/SRTP，然后只读 RTP 包丢弃（不解码），这样加压端本身不会成为瓶颈。

flowchart LR
    A["起步档<br/>12 路，跑 10 分钟 soak"] --> B["逐档翻倍<br/>25 → 50 → 75 → 100 ..."]
    B --> C{"这一档全部建连<br/>且零断连？"}
    C -->|是| D["记录 CPU/内存/出口/丢包<br/>进入下一档"]
    C -->|否| E["判定 FAIL，停止<br/>上一档 = 最大稳定并发"]
    D --> B

每一档持续 2 分钟（第一档 10 分钟 soak），全程采样节点的 CPU、内存、网络出口和 /metrics 里的会话数/丢包/丢帧；只要有一档没能全部建连，或者出现持续重连/丢帧，立刻停止，上一档就是这台机器的最大稳定并发。

1.2 同一套方法，两个机房，结果天差地别

这是这次压测最有价值的发现：同样是 2 vCPU / 2～4GB 的 standalone 节点，同样的阶梯方法，换一家云厂商，结果能差 5 倍。

LightNode（马尼拉）2vCPU/4GB
12 ████ 25 ████████ 50 ████████████████ 75 ✗ FAIL
                                        （CPU 冲到 134%/177%，建连超时，开始丢帧）

AWS Lightsail       2vCPU/2GB
12→25→50→75→100→150→200 全部 PASS ████████████████████████████████████████ 250 PASS
                                                                    300 ✗ FAIL（内存耗尽）

	LightNode（马尼拉）	AWS Lightsail
规格	2 vCPU / 4GB	2 vCPU / 2GB（内存更小）
标称出口	1 Gbps	1 Gbps
实测公网出口	约 50～106 Mbps	约 2.4 Gbps
完成的最大并发	50（75 路失败）	250（300 路因内存耗尽失败）
先撞到的资源	提供商网络限速	节点自己的内存

同一台机器规格，在 LightNode 上 75 路就崩了，换到 AWS Lightsail 反而能稳定做到 250 路——不是机器突然变强了，是第一次测的根本不是机器的天花板，而是供应商网络的隐藏限速。 这正是单机容量压测必须学到的第一课：一次压测的"失败"结论，不换个环境复测，很容易把"供应商限速"误判成"机器的真实上限"。

---

2. 最大的约束不是 CPU，是出口带宽

2.1 "标称 1 Gbps"和"实测出口"之间的巨大鸿沟

压测前先用 iperf3 对 LightNode 实例做了纯网络测试（不跑 mmx），结果很直接：三批独立实例、四个城市（马尼拉、台北、新加坡、东京），实测整机出口一律在 50～106 Mbps 之间，从未接近标称的 1 Gbps。 8 条并发流聚合上传依然卡在约 103 Mbps，排除了"单流限速"的可能，限速是在提供商的网络侧，不在虚拟机内部。

flowchart TD
    A["mmx 只转发媒体流<br/>不转码、不解码"] --> B{"出口带宽够不够？"}
    B -->|够：AWS ~2.4Gbps| C["瓶颈是 CPU/内存<br/>可以靠升级机型解决"]
    B -->|不够：LightNode ~100Mbps| D["瓶颈是网络<br/>加多少 CPU 都没用"]

mmx 只转发不转码，瓶颈通常在出口带宽和网卡，不在 CPU。 这是这几份压测报告反复验证出来的同一个结论：CPU 和内存可以通过升级机型解决，但出口带宽是云厂商这一层给定的硬约束——不实测就按标称值做容量规划，规划出来的数字几乎必然是错的。

2.2 对 Origin 和 Recorder 节点来说，网卡带宽直接决定扩容上限

这个结论不只对自建的 standalone 节点成立，对平台自己的 Origin 和 Recorder 角色更加直接——它们的核心工作本来就是"把流转发出去"，天然就是带宽敏感型：

• Origin：每接一台 Edge，就要多转发一份流出去。一个真实部署案例里，13 台 Edge × 5 Mbps ≈ 65 Mbps 私有 IP 出站，当时的机型（t3.medium）网络够用——但部署记录里特别标注了一句"若 Edge 数量进一步增加需复核"：Edge 数量翻倍，Origin 的出口带宽需求跟着翻倍，CPU 和内存不动，先顶到天花板的永远是网卡。
• Recorder：它的出口带宽要同时承担两件事——转发给备用分发线路和把录像文件上传到对象存储（EP18 讲过），两者共用同一份带宽配额。同样是一个真实部署案例：备用转发约 1.55 TB/月，录像上传约 0.78 TB/月（按入站流量的 50% 估算），合计占到带宽配额的近一半——这还只是一期的量，一旦转发路数或录像时长增加，先告警的大概率是带宽配额，不是 CPU 占用率。

flowchart LR
    subgraph O["Origin"]
        O1["收 1 路推流"] --> O2["转发给 N 台 Edge"]
        O2 -.->|"N 越大，出口带宽线性增长"| O3["网卡带宽是扩容上限"]
    end
    subgraph R["Recorder"]
        R1["收 Origin 转发的流"] --> R2["① 转发给备用分发线路"]
        R1 --> R3["② 上传录像到对象存储"]
        R2 & R3 -.->|"共用同一份出口带宽配额"| R4["网卡带宽是扩容上限"]
    end

判断"先撞 CPU 还是先撞带宽"有一套现成的方法：同时采样节点的 CPU 占用率和网卡出口速率（/proc/net/dev 的 tx 增量），在同一张图上看哪条线先触顶——出口先摸到实测带宽上限、CPU 仍有明显余量，就是带宽受限；CPU 先冲到 90% 以上、出口还没到上限，才是真的 CPU 受限。 不看这张图、只凭 CPU 占用率下结论，很容易把"带宽卡住了"误判成"机器不够强"。

---

3. 测试数据：三份真实报告放在一起看

机型	最大稳定并发	失败档位	先撞到的资源
LightNode 2vCPU/4GB	50 路	75 路	供应商网络限速（约 100Mbps）
AWS Lightsail 2vCPU/2GB	250 路	300 路	内存耗尽（仅剩 289MB → 33MB）
LightNode 1vCPU/2GB	18 路	19 路	CPU（15 秒内从 ~40% 冲到 88~103%）

3.1 退化是悬崖，不是渐变

三份报告里，CPU/资源占用都不是平缓爬升到临界点再慢慢失败的——是在某一档之后，几秒到十几秒内从"健康"直接冲到"过载"：

1vCPU/2GB 节点 CPU 占用率
10路 ██████ 26%
15路 █████████ 45%
17路 ██████████ 47%
18路 ██████████ 45%   ← 最后一档稳定
19路 ████████████████████ 88~103%   ← 15 秒内冲上去，开始丢帧

18 路到 19 路之间，按 10～18 路的斜率外推应该只到 48～55% 左右，实测却直接跳到 88～103%——没有过渡带。原因很直接：单核机器没有第二个核心去兜底 GC、网络轮询和突发处理，一旦主处理路径跟不上实时节奏，缓冲区开始堆积，丢帧/重传处理又反过来占用更多 CPU，形成自我放大的拥塞雪崩，不是优雅降级。

3.2 不能跨机型线性外推

2 vCPU 机器测出的斜率大致是"CPU% ≈ 15 + 0.97% × 并发数"，如果直接拿这条线对半估算 1 vCPU 机器的容量，会得出约 35 路的乐观值——但实测只有 18 路。少一个核心，不是少了一半算力这么简单：没有第二个核心兜底，悬崖来得早得多，也窄得多。三份报告放在一起最大的教训就是：换机型必须重新实测，不能用另一个机型的曲线去外推。

---

4. 一张图串起来

flowchart TD
    A["同一套阶梯加压方法<br/>whep-loadgen，12→25→50→75→..."] --> B["在不同机房各测一遍"]
    B --> C["LightNode：75 路崩溃"]
    B --> D["AWS Lightsail：250 路才崩溃"]
    C --> E["排查发现：LightNode 实测出口<br/>仅 ~100Mbps，不是 CPU 问题"]
    D --> F["AWS 实测出口 ~2.4Gbps 够用<br/>崩溃原因真的是内存耗尽"]
    E --> G["结论：CPU/内存能升级<br/>出口带宽是云厂商给定的硬约束"]
    F --> G
    G --> H["Origin/Recorder 同理：<br/>网卡带宽直接决定扩容上限"]

---

5. 结尾与下集预告（逐字稿要点）

这一集讲了怎么测单节点容量：同一套阶梯加压方法，分别在 LightNode 马尼拉机房和 AWS 跑一遍，同样的机器规格，LightNode 75 路就崩了，AWS 却能稳定做到 250 路——差别不在机器，在供应商的真实出口带宽（约 100Mbps vs 约 2.4Gbps）。这也是贯穿全集的核心结论：CPU 和内存可以靠升级机型解决，出口带宽是云厂商给定的硬约束，升不动；对 Origin 和 Recorder 这类天生要转发流量的角色，网卡带宽直接决定了它们能扩容到多大。三份真实压测报告还共同验证了另外两条：节点退化是悬崖式的，不是慢慢变差；不同机型之间不能线性外推，换机型必须重新实测。

下一集是这门课的最后一集。我们回到最初的那个商业问题：PPCDN 到底能为您省多少？ 主播自己的上行带宽换掉云端转码费，HEVC 省下行带宽，P2P 省 Edge 下行并把端到端时延压到 110ms 以内——我们把这三笔账一次算清，每个数字都说明它成立的条件，哪些是实测的、哪些是建模的、哪些还没验证的，一条条摊开来讲。

---