实验 2.1：短跑基线 — 100 请求串行，三架构 QPS 打平？

所属 Day：Day 2 — epoll/多进程/短连接压测 前置依赖：知识篇：两把压测尺子 · 知识篇：服务结构 更新时间：2026-08-20（重构：从原 Day 2 单篇 128KB 文档拆分，对应原 §7.1） 配套实验：长跑稳态 · syscall 归因

---

一、本实验要回答的问题

Q：100 请求量级下，LT / ET / MP 三种架构的 QPS 和延迟差多少？

Day 2 的第一个量化实验。预期三架构差异不大，但要用数据确认：瓶颈到底在架构，还是在压测工具自身的节奏？

二、实验设计

2.1 方案

• 工具：echo-bench（串行，1 连接 × 100 轮 = 100 请求）
• 机器：20 核虚拟机（shrdlab31），localhost 回环
• 服务端：LT / ET / MP 三架构，各连续跑 3 次（端口 9988）
• 补充：bench.sh 100 并发 nc + 并发扫描（10→60）

2.2 操作步骤

make all
make run-bench-lt && make run-bench-et && make run-bench-mp  # 各 3 次
bash bench.sh  # 100 并发
for c in 10 20 30 40 50 60; do bash bench.sh $c; done  # 并发扫描

三、实验数据

3.1 LT 版（100 req × 3 跑）

运行	QPS	min	P50	P90	P99	P999	max	耗时
Run 1	8352.8	102 μs	108 μs	115 μs	254 μs	254 μs	254 μs	0.012 s
Run 2	7916.4	107 μs	115 μs	122 μs	248 μs	248 μs	248 μs	0.013 s
Run 3	8059.3	105 μs	111 μs	119 μs	195 μs	195 μs	195 μs	0.012 s

均值：QPS ≈ 8109.5，P50 ≈ 111 μs，P99 ≈ 232 μs

3.2 ET 版（100 req × 3 跑）

运行	QPS	min	P50	P90	P99	P999	max	耗时
Run 1	8479.6	101 μs	106 μs	114 μs	288 μs	288 μs	288 μs	0.012 s
Run 2	7902.6	97 μs	115 μs	122 μs	206 μs	206 μs	206 μs	0.013 s
Run 3	7704.2	106 μs	115 μs	122 μs	206 μs	206 μs	206 μs	0.013 s

均值：QPS ≈ 8028.8，P50 ≈ 112 μs，P99 ≈ 233 μs

3.3 MP 版（4 workers，100 req × 3 跑）

运行	QPS	min	P50	P90	P99	P999	max	耗时
Run 1	8656.5	85 μs	105 μs	115 μs	243 μs	243 μs	243 μs	0.012 s
Run 2	8012.2	87 μs	115 μs	123 μs	183 μs	183 μs	183 μs	0.012 s
Run 3	7975.1	92 μs	117 μs	127 μs	210 μs	210 μs	210 μs	0.013 s

3.4 三架构 3 次均值对比

维度	LT	ET	MP	赢家	差异
QPS 均值	8109.5	8028.8	8214.6	MP	MP vs LT +1.3%，vs ET +2.3%
min	105 μs	101 μs	88 μs	MP	MP -16%
P50	111 μs	112 μs	112 μs	三者相等	差异 < 1%
P99	232 μs	233 μs	212 μs	MP	MP -8.6%
P99 极差	59 μs	82 μs	60 μs	LT 略胜	LT 最稳

3.5 bench.sh 并发测试（100 nc &）

运行	ET QPS	LT QPS	MP QPS	最快
1	3736	2936	2382	ET
2	1493	3323	1870	LT
3	3946	3839	2985	ET
4	3783	3829	—	LT

并发扫描（10→60，20 核机器）：

Concurrency	ET QPS	LT QPS	MP QPS
10	187	36	217
20	455	418	395
30	626	551	561
40	673	694	590
50	753	713	726
60	823	752	792

四、实验分析

4.1 三架构 QPS 几乎打平（差距 < 3%）

串行 100 req 下，LT/ET/MP 均值 8.0K-8.2K。瓶颈不在架构，而在 bench 进程自身的 connect() 节奏：单进程 recv()→send() 之间至少 2 次 syscall（约 2-3 μs），与请求量线性相关；100 req 时"测试器开销"占比约 30%。

4.2 MP 延迟尾部反胜，LT 稳定性最优

• MP min/P99/max 三项最优（-8.6% ~ -16%）：4 worker 分散接管延迟
• LT 3 跑 P99 极差最小（59 μs < MP 60 μs < ET 82 μs）：水平触发唤醒稳定
• ET P99 波动最大（288→206→206）：边缘触发"第一次唤醒的循环深度随机"放大尾部方差

4.3 短跑的两个盲区（必须长跑才可见）

1. 冷启动占比高：短跑 QPS 8K vs 长跑稳态 17.6K（2.17×）——前 10 个请求承担全部一次性冷启动开销
2. TIME-WAIT 不可见：100 req 只产生 ~100 个临时端口，远低于 28231 上限——端口耗尽必须 ≥1000 req

4.4 bench.sh 并发下 MP 反而最慢

100 个短连接不足以让 SO_REUSEPORT 并行优势发挥，却引入了 4 个 epoll 实例维护、master 信号管理开销——多进程真正价值在长连接密集型场景（Day 3+ 验证）。并发扫描显示：QPS 次线性增长（4.4×/6× 并发），瓶颈是短连接固定税（TCP 握手/挥手 + 进程创建销毁 ~300μs/连接），远大于 epoll 处理差异（~50μs/连接）——epoll 通知机制差异在短连接下被稀释。

五、实验结论

#	结论	证据
1	串行短跑三架构 QPS 打平（< 3%）	LT 8109 / ET 8029 / MP 8215
2	MP 延迟尾部反胜（min/P99/max 最优）	MP P99 212 vs 232/233 μs
3	LT 稳定性最优（P99 极差 59 μs）	LT < MP 60 < ET 82
4	短跑无法区分 LT/ET 真实差异	均值 < 1.1%
5	短跑有盲区：冷启动污染 + TIME-WAIT 不可见	QPS 8K vs 长跑 17.6K
6	bench.sh 并发下 MP 最慢、LT 最稳	MP 2.4K vs ET 3.7K

六、回答开头的问题

Q：100 请求量级下，LT / ET / MP 三种架构的 QPS 和延迟差多少？

答：QPS 几乎打平（8.0K-8.2K，差距 < 3%）——瓶颈在压测工具自身节奏而非架构；延迟上 MP 的 min/P99 略优（-8.6%~-16%）、LT 最稳（P99 极差 59 μs）、ET 尾部波动最大（82 μs）。结论是：短跑测不出架构差异，必须放大到 10000 req 长跑（见 exp-long-run.md）才能看到稳态吞吐与失败模式。

---

一句话总结：短跑 100 req 三架构打平、MP 延迟略优——真正的架构差异被"冷启动 + 测试器自身 syscall 节奏"掩盖，需要长跑才能现形。