benchmark.md

# libuvcpp 每连接内存与吞吐实测

这一页是一次**可复现的靶场实测记录**，被测对象是**用本库构建出来的一个真实 HTTP 服务**，
不是微基准，也不是估算值。写它的直接动机是回答一个具体问题：

> 一台机器上一百万条空闲长连接，要吃掉多少内存？

| 项 | 值 |
|---|---|
| **测量版本** | **1.1.33**（`534e4ed`） |
| 撰写时 `master` | `1.1.35-dev`（`d46b6eb`） |
| 口径收口于 | tag `v1.2.0`（为什么收口在这里、以及 1.2.0 为什么不在测量路径上，见 §1） |
| 被测服务 | 靶场：静态文件 + 动态路由 + 上传下载 + WebSocket + TLS 的完整 webapp |
| 平台 | Windows 10 Pro 1903（18363）/ MSVC x64 / Release |
| 运行时 | 单事件循环线程（下文另注明） |

**三个读数**（方法、分档与原始数据见下文各节）：

- **每连接内存 4.62 KiB**（4 734 B，最小二乘，**R² = 0.999987**）⇒ 外推 100 万连接 ≈ **4.42 GiB**
- 单核动态路由 **75 k RPS**（流水线 10–50 深可到 **88 k**）；静态 **44 k RPS / 107 MB/s**
- 10 分钟长跑 **3 840 万请求、0 错误**，RSS 漂移 **0.2%**

上面那三个读数是**本机靶场**（§4.1–4.4）。**平台那一套装置**（HttpArena，64 核参考机、
平台自己的生成器）的读数在 **§4.5**，其中 **1.7.0 那一轮**相对上一轮发布版 `v1.6.1`
的提升一览就是那一节的第一张表 —— 一句话版本是：h3 那一格 **×20 121**（58 → 1 167 034
req/s）、ws 流水线 **×2.3 ~ ×2.8**、`baseline-4096` **+44%**、`pipelined-4096` **+88%**、
`json-*` **+67% ~ +81%**、`static-h2` 的**常驻内存 3.7 GiB → 793 MiB**（吞吐同时 +54%），
而 42 档的 `5xx` 全为 0。

---

## 1. 为什么这是「1.1.33 的读数」，以及它为什么对后面几版仍然成立

测量发生在 `534e4ed`（1.1.33）。写明这件事是**必要条件**：一个不带 commit 的读数值
不是结论，是传闻。

`534e4ed` 之后到本文撰写时的 `d46b6eb`（1.1.35-dev）之间，**`src/` 下只动了三个文件**：

```
src/uvcpp/uvcpp_version.h      |  2 +-          ← 版本号
src/web/uvcpp_http_server.cpp  | 31 +++++-----  ← 压缩变体表的字节账
src/web/uvcpp_http_server.h    | 10 ++++++-
```

其余全是文档、CI、测试与发布打包。逐个说清它们为什么不在本文的测量路径上：

| commit | 动的东西 | 在本文测量的路径上吗 |
|---|---|---|
| `4710479` | 版本号 1.1.33 → 1.1.34 | 不涉及 |
| `d56c2a4` | 压缩变体表的字节账：把会漂移的计数字段换成从容器派生的求和，并补上「字节上限」那条腿 | **不在** —— 见下 |
| `d46b6eb` | 发布包同时提供 Debug 档动态库与 PDB（`uvcppd.dll` / `libuvcppd.so`），只改打包器与 CI 判据 | 不涉及 Release 运行时 |

`d56c2a4` 只影响「变体表超过上限时淘汰谁」，且只在**压缩缓存的冷路径**上；本文测的是连接
内存、动态/静态吞吐、长跑稳定性，都不经过那条路径（本文这一版连压缩都没开）。

**因此：下面的读数对 1.1.33 – 1.1.35-dev 这条线成立**；版本号只升不改功能时（1.2.0 属此
列）同样成立。真去动了上面那三条路径的话，这一页需要重测 —— 复现方法在第 8 节。

上面两段是**撰写时的快照**（`d46b6eb`）；收口在**发布提交**上：`534e4ed..v1.2.0`
（`d67f1f4`）在 `src/` 下仍然只有同样三个文件 —— `uvcpp_version.h`、`uvcpp_http_server.cpp`、
`uvcpp_http_server.h`。`uvcpp_version.h` 在那张表里是 `2` 行、到这里是 `8` 行，差的是发版
时把 `UVCPP_VERSION_IS_RELEASE` 置 `1` 与版本号 1.1.35 → 1.2.0，**不是新代码**；另两个文件
的改动量逐字相同。所以 **1.2.0 这一版照样不在本文的测量路径上**，下面的读数对发布版成立。

（锚点用 tag `v1.2.0` 而不是「最新一次发布」：tag 不会动，而后者会随下一个版本改变所指。）

---

## 2. 方法：为什么是外推，而不是真的造满一百万

**真造不满。**本机在 **54 852** 条时开始出现 `ENOBUFS` —— 那是动态端口与内核缓冲到顶，
不是服务端拒绝。换平台也一样有这条墙，只是位置不同（对照项目在自己的 Linux 环境里撞到的
是同一量级的另一个数）。所以百万级只能外推，而外推要立得住，就必须有判据。

做法是**多档位建立连接 + 最小二乘回归 + R²**：每档记「建立 N 条连接后的进程 RSS」，对 N
做一次线性拟合，斜率就是每连接内存，再外推到 1e6。判据不是"斜率好看"，是**R² 必须接近
1**，且每档残差要小 —— 否则那条直线根本不存在，外推就是编。

- 采样对象是**进程 RSS**（`WorkingSet64`），即**用户态**每连接开销；内核侧的 TCP 缓冲
  （每连接约 4 KB 量级）不在其中，也不受本库控制 —— 第 6 节比较时会回到这一点。
- 每档建立连接后**逐条复检**该连接可服务（不是"连上就算"）。
- 关闭后复检句柄数回落，确认没有把连接泄漏成别的形状。

---

## 3. 结果一：每连接内存

下表有**两列 RSS，是两个不同的量**，别混：

- **建立后 RSS** —— 连接全部建好、攥住时读的。**拟合用的就是这一列。**
- **关闭后 RSS** —— 全部断开之后再读的。它是**另一条线**，只用来佐证连接被回收干净
  （本节末单说）。

八档采样（原点 + 7 个非零档）：

| 目标并发 | 实际建立 | 连接失败 | 探测成功 | **建立后 RSS**（拟合用） | 关闭后 RSS / 句柄 |
|---:|---:|---:|---:|---:|---|
| 0（基线） | — | — | — | **9.402 MiB** | — |
| 8 000 | 8 000 | 0 | 8 000 | 46.277 MiB | 17.398 MiB / 184 |
| 16 000 | 16 000 | 0 | 16 000 | 82.602 MiB | 24.320 MiB / 184 |
| 24 000 | 24 000 | 0 | 24 000 | 118.477 MiB | 31.324 MiB / 184 |
| 32 000 | 32 000 | 0 | 32 000 | 154.238 MiB | 38.531 MiB / 184 |
| 40 000 | 40 000 | 0 | 40 000 | 190.652 MiB | 45.133 MiB / 184 |
| 48 000 | 48 000 | 0 | 48 000 | 226.727 MiB | 52.715 MiB / 184 |
| 55 000 | **54 852** | 148（`ENOBUFS`） | 全部 54 852 | 257.270 MiB | 59.094 MiB / **184** |

- **零连接失败**直到 48 000。
- 每一档都逐条复检过 8 000 – 54 852 条连接**全部可服务**。
- 全部关闭后句柄回落到 **184**（与基线一致，无泄漏）。
- 原点那档是**进程空转时的基线**（9 859 072 B），即 8 个点里的第 8 个。

**拟合（8 个点，y 单位 MiB）**：

```
RSS(MiB) = 0.0045143 × N + 9.954        R² = 0.9999869
         = 4.62 KiB/连接 × N + 9.95 MiB
```

逐点残差（**这一列要能让人自己算**）：

| N | 建立后 RSS (MiB) | 拟合预测 (MiB) | 残差 | 残差 % |
|---:|---:|---:|---:|---:|
| 0 | 9.402 | 9.954 | −0.551 | −5.86% |
| 8 000 | 46.277 | 46.068 | +0.210 | +0.45% |
| 16 000 | 82.602 | 82.182 | +0.420 | **+0.51%** |
| 24 000 | 118.477 | 118.296 | +0.180 | +0.15% |
| 32 000 | 154.238 | 154.410 | −0.172 | −0.11% |
| 40 000 | 190.652 | 190.525 | +0.128 | +0.07% |
| 48 000 | 226.727 | 226.639 | +0.088 | +0.04% |
| 54 852 | 257.270 | 257.571 | −0.301 | −0.12% |

- **除原点外每点 |残差| ≤ 0.51%**；而上表能看出这些残差**没有走向**（在零点附近交替），
  不是单向偏。
- 原点那点自己偏 −5.86%：它是**空转基线**这一次单独的读数，不落在拟合线上 —— 拟合出的
  截距 9.954 MiB 比它高 0.55 MiB。写出来是因为"除原点外"这句话要是没有上面那张表，读者
  没法知道偏多少。
- 截距 9.95 MiB 是进程的固定开销（静态缓存、会话表、已初始化的协议层等），不是每连接的。
- **外推 100 万连接 ≈ 4.4085 GiB（斜率）+ 0.0097 GiB（截距）≈ 4.42 GiB。**
- 每连接 **4 733.6 B = 4.6226 KiB**，本文按 4.62 KiB 记。

**为什么能这么低**：本库**没有每连接常驻的读缓冲**。读是
`read_start([](uvcpp_buf* b){ … })` 的按需形状 —— 有数据才给缓冲，空闲连接上不预置任何
一块固定大小的读缓冲。这一条是第 6 节那个对照的全部原因。

### 「关闭后」那一列是另一条线，不能拿去验上面的拟合式

上表最右列（关闭后 RSS）**自己对 N 回归**，出来的是：

```
RSS(MiB) = 0.0008870 × N + 10.120     R² = 0.9997352
         = 930 B/连接
```

斜率是 **5.09×** 的差（4 733.6 ÷ 930.1），R² 也不是上面那个 0.9999869。**这两个数都对，
但它们量的不是同一件事**：关闭后读到的是一条正在被回收的服务端连接表的残余占用，不是
「多一条连接要多多少内存」。**要判定容量，看的是「建立后」那条线。**

这一列自己的价值在另一头：它的**截距 10.120 MiB 与空转基线 9.402 MiB 只差 0.72 MiB**
（约 7.7%）。这才是"连接被回收干净"的证据 —— 8 000 到 54 852 条连接全关掉之后，进程回到
离基线不远的地方，且**句柄一律回到 184**。所以这一列留着，但它是**证据**，不是**斜率**。


---

## 4. 结果二：吞吐与延迟

动态路由（内存型响应），单事件循环：

| 用例 | 并发 | 流水线 | RPS | p50 | p99 | max | 错误/超时/503 |
|---|---:|---:|---:|---:|---:|---:|---:|
| json | 1 | 1 | 44 946 | 0 ms | 0 ms | 1 ms | 0 |
| json | 10 | 1 | **75 791** | 0 ms | 0 ms | 1 ms | 0 |
| json | 400 | 1 | 71 614 | 5 ms | 6 ms | 27 ms | 0 |
| json | 1 600 | 1 | 63 278 | 25 ms | 28 ms | 101 ms | 0 |
| json | 100 | **10** | **88 134** | 10 ms | 16 ms | 28 ms | 0 |
| json | 100 | **50** | 87 874 | 56 ms | 65 ms | 94 ms | 0 |

静态文件（走工作线程池）：`44 379 RPS / 107 MB/s`（并发 100）、`43 154 RPS / 104 MB/s`
（并发 400）。256 KB 大响应：`1 608 RPS / 402 MB/s`。

**要点**：到并发 1 600 仍零错误、零超时、零 503，延迟线性劣化但不掉请求；流水线
（10–50 深）把单核推到 88 k RPS。

**静态服务没有并发悬崖**：1 → 200 并发共 12 档打静态文件，**每一档 503 占比都是 0%**，
成功 RPS 从 15 879 升到峰值 **45 044**（并发 12）后平在 43 563（并发 200）。作为对照，
同一台机器上纯内存路由是 44 501 → 73 480。

### 4.1 PR #24 的两处热路径改动（**作者自测，另一套装置**）

> **这一小节的读数不在上面那套装置上。** 它是 PR #24 作者用自己的靶场做的 A/B
> （100 并发 × 15 s × 4 轮，两档**交替**跑）。**绝对值与本节表格不可比** ——
> 有意义的是同一台机器上的**差值**。按既定口径，性能读数**暂用作者发来的**，
> 后续复测再更新这一节。

两处都是"纯白付"：

1. **读缓冲不再清零 —— 每请求 128 KiB。** `uvcpp_buf::alloc_buf()`
   （`src/uvcpp/uvcpp_buf.cpp:474-474`）原先走 `uvcpp_alloc_arry<char>()`，而
   `uvcpp_alloc_*` 全是 **calloc 语义**（分配后整块 `memset` 0，
   `src/uvcpp/uvcpp_alloc.h:45,109`）。这块内存是交给 libuv 的 alloc 回调**接数据**
   的，紧接着就被 `WSARecv` 整块覆盖 —— 清的字节一个都留不下。代价是**量出来的**：
   libuv 对 TCP 流给的 `suggested_size` 是 **64 KiB**，而一条连接在**一次请求**里会让
   alloc 回调跑**两趟** ⇒ 每个请求 **128 KiB**，而请求本身只有百来字节。现在改走
   `uvcpp_buf.cpp` 匿名命名空间里的 `alloc_raw()`（`src/uvcpp/uvcpp_buf.cpp:462-462`，
   契约是"读之前不能假设它是 0"）
   —— **不给它公开的位置**：`uvcpp_alloc_*` 那一族的约定就是"全部清零"，同前缀、
   同形状、唯独不清零的兄弟放进去是个陷阱。它不是公开 API，这是有意的。
2. **响应序列化不再走 `ostringstream`**：`uvcpp_http_response::to_string()` 改成
   `std::string` 直接拼 + `reserve(est)`，状态码与 content-length 两个整数用十行的
   `append_dec` / `append_hex`（绕开 num_put 的 locale、sentry 与虚调用）。

| | QPS | 用户态 µs | 合计 µs | 合计 µs 轮间散布 |
|---|---:|---:|---:|---:|
| 基线 | 101 251 | 4.8500 | 9.8765 | 0.1431 |
| 改动后 | **115 085** | **3.9469** | **8.6896** | 0.1797 |

合计 **−13.66%**、用户态 **−22.88%**、QPS **+12.02%**；第二轮独立复量得 **−15.29% /
−27.84% / +13.17%**。两处差值都在轮间散布之外，全部轮次 0 非 2xx；9 个端点的原始报文
逐字节一致（1 312 B）。拆开单独开关：读缓冲约 **−9.8%**、序列化约 **−2.5%**。

**为什么是"两档交替"而不是跑两遍**：本机 µs 会漂 —— 同一份代码跨会话能从 102 943 漂到
113 802（**+10.5%**），而**同一轮内**散布只有 0.12 µs。所以判据取「|差| > 双方轮间
散布」，而不是两次独立读数的绝对值。

**试过但没采纳**：把读缓冲封顶到 8 KiB（−0.49%，落在散布内，白搭）。而且**不能封在
`alloc_buf()` 里** —— 它同时给 UDP 用（`src/net/uvcpp_udp_server.cpp:165`、
`src/net/uvcpp_udp_client.cpp:956-956`），而 UDP 是数据报，缓冲小了会**截断报文**。

### 4.2 接受连接时默认关 Nagle（**另一套装置**，轮流 A/B）

> 同 4.1 的口径：这一节的读数不在上面那套装置上，而是 **HttpArena 的条目在这台机器上
> 裸机跑**（同一个 `h2load`、同一份条目二进制，两臂**交替**，各三轮）。绝对值与本节表格
> 不可比 —— 有意义的是**同一轮内两臂的差**与**同一条连接上的对照**。

**缺陷**：libuv 建出来的 socket **不设** `TCP_NODELAY`，于是 Nagle 是开的。一次应答只要
被写成**两段**、每段都小于 MSS，第二段就被压在发送缓冲里等对端的 ACK；而对端此刻没有
数据要回，走的是 Linux 的 **40 ms 延迟 ACK** ⇒ 这一笔应答平白多出 40 ms。h2 上的 gRPC
应答正是两段（头块+DATA 一段、尾随头一段）。

**判据不是"变快了"，是"那个 40 ms 定时器没了"。** 同一台服务器、同一个 `h2load`、同一条
回环上，h1 路由（整条报文一次 `uv_write`，一段）的 `request` 中位数只有 **21 µs** —— 这个
对照组把"回环的固有成本"钉在几十 µs 那一档；而 h2c 上同一条 gRPC 路由是 **41.00 ms**。
三者一比，那 40 ms 只能来自应答的第二段在等人。

| 形状（`h2load`，`-D 5s`，gRPC 请求体是 9 字节帧） | base（改动前） | fix（改动后） |
|---|---:|---:|
| h2c gRPC `-c 1 -m 1` | **24.20 rps**；五秒 **121** 个；`request` 中位 **41.00 ms** | **25 687 / 26 569 / 29 489 rps**；五秒 12.8–14.7 万个；中位 **29 µs** |
| h2c gRPC `-c 64 -m 1` | 1 541 / 1 553 / 1 554 rps；中位 **41.01 ms** | **175 498 / 182 635 / 242 849 rps**；中位 149–229 µs |
| h2c gRPC `-c 256 -m 100` | 594 000 / 595 500 / 529 901 rps | 646 040 / 477 952 / 654 301 rps |
| h2 gRPC over TLS `-c 256 -m 100` | 587 550 / 587 172 / 409 423 rps | 619 631 / 496 094 / 523 543 rps |
| **h1 对照** `-c 1 -m 1` | 39 106 / 41 975 / 42 322 rps；中位 21 µs | 41 587 / 38 618 / 43 134 rps；中位 22 µs |
| **h1 对照** `-c 256 -m 100` | 1 222 788 / 1 555 136 / 1 566 292 rps | 1 583 476 / 1 228 199 / 1 611 052 rps |
| `curl`（客户端自带 `TCP_NODELAY`）单连接打 h2c gRPC，`≥30 ms` 的占比 | 9/30、10/30、15/30 | **0/30、0/30、0/30** |

36 格全部 `0 failed / 0 errored / 0 非 2xx`。三条读得出来的结论：

1. **只在"一条连接上一个请求在途"时咬人**：`-m 1` 两档约 **1 100×** 与 **120×**。
2. **`-m 100` 的持续流水上量不出差别** —— 两臂落在彼此轮间散布里（同一臂三轮自己就能差
   ±15%）。ACK 一直在流，Nagle 最多压住一个 RTT，回环上那是几十 µs、不是 40 ms。
   **所以别把这条当成吞吐优化的战果**：HttpArena 的档位都是 `-m 32` / `-m 100`，它不解释
   榜单上的任何一格。它修的是低并发请求/应答的时延 —— `curl` 那一行是同一件事的另一个
   侧面：客户端自己带 `TCP_NODELAY` 也救不了服务端的第二段。
3. **h1 的两条对照一格没动。** 这是"归因落在两段式应答"而不是"`TCP_NODELAY` 让什么都
   快了"的证据；少了它，第 1 条那两位数的倍率也能被解释成别的东西。

**这套量具的一个坑（记在这里免得下次再踩）**：A/B 是"同一个条目二进制、只换
`LD_LIBRARY_PATH` 下的 `libuvcpp.so`"，所以**必须验证"8080 的持有者就是这次起的那个进程、
它 `/proc/<pid>/maps` 里加载的就是本变体那份 `.so`"**。第一版的启动脚本写成
`( cd X && setsid env … & echo $! > pid )`：`&` 作用在整个 AND 列表上，bash 会为它再 fork
一层子 shell，`$!` 记到的是那层子 shell 而不是 server ⇒ pid 文件从第一轮起就是死的，泄漏
的 server 一直占着 8080，之后每个新 server 都**绑不上就静默退出**，30 格读数其实全来自
同一个进程 —— 两臂的数字因此一模一样，差点被当成"这个修复没用"。修法就是那两条断言：
起完核端口持有者，再核 `/proc/<pid>/maps`。

### 4.3 每请求的用户态指令数（**另一套装置**，callgrind）

> 同 4.1 / 4.2 的口径：这一节的读数**不在**上面那套装置上，也不是 rps。它是
> `valgrind --tool=callgrind` 数出来的**每请求指令数** —— 同一个条目二进制、同一条
> `gcannon` 命令行、同一档核绑定，**只换 `LD_LIBRARY_PATH` 指向的那份 `libuvcpp.so`**。
> **绝对值与本节表格不可比**，跟 4.1 / 4.2 的 µs 也不可比；有意义的是**同一个会话内的差**。
> 装置搭法、六个格式与流程上的坑、以及 `/proc/<pid>/io` 那两次被**证伪**的假设，记在
> [`benchmark-rig.md`](benchmark-rig.md) 的「每请求指令数的量具（callgrind）」一节。

**为什么这次不信 rps 而信指令数**：这台机器的 CPU 跑在 `powersave` 调频档上，同一个
二进制跨会话的 µs/请求能漂 **35%**；callgrind 数的是指令，**与频率无关** —— 同一份 `.so`
四轮下来得 `11 283.3 / 11 284.9 / 11 287.7 / 11 291.8`，**散布 0.075%**。判据因此取
「|差| > 双方自身散布」，跟 4.1 那条是同一个道理。

本轮改了三处（`1.6.17-dev`，逐处说明见 CHANGELOG 的「性能」组）：
`web_parse_query` 按 `&` 的个数预留、`to_string_into` 的响应头表四趟并成一趟、
状态行不再为字面量造 `std::string`。

| 读数（h1 `/baseline2?a=1&b=1`，`-c 2000`、5 s 窗口、callgrind 增量段） | 每请求指令数 |
|---|---:|
| 改动前（四轮） | 11 283.3 / 11 284.9 / 11 287.7 / 11 291.8 |
| 只换序列化（`to_string_into` + `size_to_string`） | 11 205.1 / 11 211.7 |
| 再并上头表遍历、加上查询预留 | **10 925.1 / 10 927.5** |

同一会话内夹逼 **11 286.3 → 10 927.5 = −358.8 条/请求（−3.18%）**；把四轮改动前与两轮
改动后**全部交叉配对**，区间是 **−355.8 ~ −366.7（−3.15% ~ −3.25%）**。

逐函数归因（`so-after3 → so-after4` 这一段，同一会话，合计 **−286.6**）：

| 函数（每请求） | 前 | 后 | 差 |
|---|---:|---:|---:|
| `vector<pair<string,string>>::_M_realloc_insert` | 154.9 | **0** | −154.9 |
| `malloc` / `_int_free` / `free` / `operator new` / `operator delete` | — | — | **−135.7** |
| `__strlen_avx2` | 239.6 | 225.4 | −14.2 |
| `uvcpp_http_response::has_header(const char*)` | 60.4 | 50.3 | −10.1 |
| `web_parse_query`（新增的数 `&` 循环） | 29.2 | **75.4** | **+46.2** |

`_M_realloc_insert` 归零加上分配器那一簇是**查询预留**（净 **−242.4**），`has_header`
连同 `__strlen_avx2` 是**头表合一**（约 **−44**）。序列化那一半落在
`to_string_into` **100.5 → 57.3**、`size_to_string` **76.4 → 65.4** 上，单独量是
**−78.5**（11 286.9 → 11 208.4，与上面那两轮 11 205.1 / 11 211.7 的区间不重叠）。

**改动后的画像**（每请求，前几名）：`__memcpy_avx_unaligned_erms` 862.2（7.89%）、
`string::_M_append` 665.7（6.09%）、`malloc` 523.2（4.79%）、`_int_free` 487.6（4.46%）
—— 分配器那两名合计 **11.0%**，是下一刀的方向；`uvcpp_buf::free_own` 232.7（2.13%）、
`vector<http_header>::emplace_back` 187.9（1.72%）紧随其后。

**试过并整体退回**：把 `web_url_decode` / `web_collapse_slashes` 改写成原地版本
（外加 `take_from` 少一次拷贝）这一整包，在同一量具上是 **+328.6 条/请求** ——
`web_url_decode` 每请求被调 **5.03** 次，其中 4 次是 1 字节的查询键/值，原地版省下的
那次拷贝抵不过多出来的一趟扫描。三处留下来的改动都只动**自己这一趟**、不改任何分支
结果，报文逐字节不变（`to_string()` 与 `to_string_into()` 仍是同一份实现，
`tests/functional/web_app_response_func.cpp` 那条逐字节比对继续覆盖）。

### 4.4 静态文件发盘上孪生（**第三套装置**，探针 + `h2load -p http/1.1`）

> 又是另一套装置：这一节的读数**不在** 4.1 / 4.2 的条目上，也不是 4.3 的指令数。它是一支
> 仓外探针（`probe.cpp`）**一次只起一条静态腿**、`h2load -p http/1.1` 打同一份
> `data/static`（20 个文件 + 30 个孪生）。**绝对值与前几节都不可比**；有意义的是**同一
> 会话内同一台机器上的开/关两臂之差**。装置搭法、三个坑（**语料的文件系统**、`-m` 的
> 含义、`-c 256` 的双峰），记在 [`benchmark-rig.md`](benchmark-rig.md) 的
> 「预压缩孪生：两条静态腿各自的探针」一节。

**要回答的问题**：静态响应在服务端是**每请求现场 deflate 一整份文件**（响应变体缓存按
`resp.cache_tag` 做键，而 `uvcpp_static_server` 到 `1.6.44-dev` 为止都不填它 ⇒ 那个缓存对
它形同虚设，见下），那么"盘上放一份早就压好的孪生、直接发它"值多少？两条静态腿是两份不同
的实现，得分别量。

**这一节在 `1.6.44-dev` 上重跑过（2026-10-14），因为那两条腿的起点变了**：
`uvcpp_static_server` 从 `1.6.44-dev` 起也填 `resp.cache_tag`（从前全仓只有
`uvcpp_web_static` 填），"关"那一臂于是不再是"每请求重压一遍"。下表每一臂都是**同一次
会话内交替跑 3 次取中位数**：

| 腿（ext4 语料、8 循环、`-c 64 -m 2 -n 8000`） | 发盘上孪生**关** | **开** | 差 | 8000 请求送出字节 |
|---|---:|---:|---:|---:|
| `uvcpp_static_server`（`static-h3` 那条腿） | 66 554.63 rps | **89 791.80** rps | **+34.9%** | 173 843 446 → 131 194 904（−24.5%） |
| `uvcpp_web_app::serve_static`（`static-h2` / `static-tls`） | 68 464.43 rps | **92 262.63** rps | **+34.8%** | 173 843 446 → 131 194 904（−24.5%） |
| `uvcpp_static_server`，**把 `cache_tag` 也关掉**（`1.6.44-dev` 之前的形状） | 977.00 rps | — | — | 173 843 446 |

（三次原始读数：`srv` 的 pc=0 为 67 303.24 / 66 554.63 / 64 449.08、pc=1 为
89 791.80 / 90 780.14 / 84 193.69；`app` 的 pc=0 为 62 364.55 / 68 464.43 / 71 858.44、
pc=1 为 92 262.63 / 92 065.14 / 92 707.40；第三行 941.33 / 979.10 / 977.00。）

三条读得出来的结论：

1. **那 88× 曾经是真的，现在不是了 —— 但它从来不是这个选项的功劳**。第三行是**消融臂**：
   同一份源码，只把 `fill_cached_response()` 里填 tag 的那一段关掉、单独链一份
   `libuvcpp.so`，其余一个字节不改。它复刻出旧版的 933.15 rps（今天 977.00）那个量级 ——
   每请求在**循环线程**上把整份文件 deflate 一遍（`compress_enabled_` 默认就是 true，
   而变体缓存按 `cache_tag` 做键，本类从前不填 ⇒ 缓存对它不生效；20 个文件平均 63.6 KB、
   最大的 `app.js` 204 800 B ⇒ 每请求 2 ~ 7 ms 的 zlib）。**补上 `cache_tag` 让这一臂跳到
   66 554.63（68.1×）**，这个选项自己只剩 66 554.63 → 89 791.80（+34.9%）。旧版把
   977 → 89 792 那 91.9× 整个记成了"发孪生省的"，那是归因错了。
2. **两条腿现在几乎重合（+34.9% 对 +34.8%），因为它们的起点终于一样了**。从前
   `uvcpp_web_app` 那条腿是 +67%、`uvcpp_static_server` 是 88×，差这么远不是孪生对两条腿
   价值不同，而是**它们开孪生之前的起点不同**（一条已经压一次缓一次，另一条每请求重压）。
   把 tag 补齐之后这个选项只剩它自己该做的事：**换字节数**，外加省掉那**一次**压缩。
3. **字节那一栏与文件系统无关，也不全是 brotli 省下来的**。盘上 20 个文件共 1 271 603 B，
   其中 15 个有孪生（br 224 029 B / gz 262 407 B，br 比 gz 再少 14.6%），另外 5 个
   webp/woff2 没有孪生、按原样发（101 376 B）—— 即盘上「br + 原样」325 405 B 对
   「gz + 原样」363 783 B，纯带宽那一份是 10.5%。

**一条口径要写在前面**：`precompressed=0` 那一臂发出去的**不是原文件**，是实时 deflate
出来的 gzip —— 它每圈 20 个 URI 送 431 160 B（= 172 463 836 ÷ 400 圈），比盘上那套 `.gz`
孪生（含 5 个无孪生文件共 363 783 B）**还大**。所以别把这张表读成"发原文件 vs 发压缩件"，
它是"**现场压** vs **发盘上那份**"。

**旧版那一节的绝对值（`srv` 的 933.15 → 82 451.28、`app` 的 110 773 → 185 280）不要再引用**：
它们是在更早的树、更早的机器状态下量的，而**同一台机器今天整体慢得多** —— 把 `1.6.18`
那份发布包挂上同一装置、跑同一条孪生命令（那条路与今天**逐字节同策**，只是没有
`cache_tag`），`srv` pc=1 只得 78 174 ~ 79 411、`app` pc=1 得 74 663 ~ 83 365，而当时那一臂
记的是 82 451.28 / 185 280。**跨会话的绝对值在这套装置上不可比，只有同一次会话内的比值可比** ——
这也是本节开头那条口径的真正含义。

### 4.5 平台自己的读数（HttpArena，**第四套装置**）

> 这一节的数字**没有一个是在本机量的**。它们来自 [HttpArena](https://github.com/MDA2AV/HttpArena)
> 平台自己的机器与自己的生成器（按家族分别是 `gcannon` / `h2load` / `wrk` / `zrk`），
> 一档一档跑，被测对象是本库 —— 条目目录 `frameworks/libuvcpp` 就是这份源码的一份薄封装
> （一个 `main.cc` 加一个 `Dockerfile`）。平台把每一档的原始读数提交回推送条目的那条分支
> （`site/data/results/libuvcpp.json`），所以下面这些表都是**可复核的**，不是从网页上抄的。
> **绝对值与 4.1–4.4 一概不可比**：换机器、换生成器、换并发形状。有意义的是它们本身
> （榜单就是拿这些数打分的），以及 `2xx` / `5xx` 两栏 —— 那是每档的**正确性**事实。

参考机是**单路 AMD Threadripper PRO 3995WX**（Zen 2，64 物理核 / 128 线程，8 通道
DDR4-3200，单 NUMA 节点）。多数档把服务端钉在 `0-31,64-95`（32 个物理核 / 64 个线程，
跨 CCX 0–7），生成器拿另一半 `32-63,96-127` —— 半个芯片压，半个芯片抗。表里 `CPU` 那一栏
是**相对单线程**的百分比：`6 099.8%` 就是 61 个线程在跑，离它那 64 线程的配额只差一点。

#### 1.7.0 的读数（2026-10-14，42 档）

条目在榜上跑过**七轮**（10-13 那天跑了两次），这一节是**第四轮**，后面依次是第五、六、七轮。
第四轮也是 1.7.0 自己那一轮：被测的那棵树是 `ae437de`，库钉在 `6eede33`，即 1.7.0 之前的
`1.6.51-dev`。它与 1.7.0 之间在 `src/` 下只差两处 ——
`src/db/` 那两个后端改成了运行时加载，以及版本号那一行：

```sh
git diff 6eede33..v1.7.0 -- src/ ':!src/db'      # 只剩 src/uvcpp/uvcpp_version.h 一行
```

`src/db/` 那部分是 `UVCPP_DB_RUNTIME_LOAD` 的运行时加载（默认关，条目一条都没开）；
1.7.0 里新加的 `--exclude-libs,ALL` 只改动态符号表，不改一个字节的代码。
**所以下面每一个数就是 1.7.0 的数。**

同名 26 档里，一眼看得出的提升：

| 提升在哪 | 第二轮 `v1.6.1` | **1.7.0** | 倍数 |
|---|---:|---:|---:|
| `baseline-h3-64`（h3 短包头解码） | 58 | **1 167 034** | **×20 121** |
| `echo-ws-pipeline-512` / `-4096` / `-16384` | 10 846 084 / 12 632 957 / 10 629 843 | **30 027 149 / 28 938 721 / 25 179 465** | ×2.77 / ×2.29 / ×2.37 |
| `async-32000` | 725 202 | **1 513 512** | ×2.09 |
| `pipelined-4096` | 3 612 234 | **6 784 375** | ×1.88 |
| `json-tls-4096` | 370 872 | 672 436 | ×1.81 |
| `json-comp-4096` / `-16384` | 194 410 / 192 334 | 325 476 / 321 152 | ×1.67 |
| `static-tls-1024` | 115 239 | 190 096 | ×1.65 |
| `static-h2-256` / `-1024` | 149 781 / 157 097 | 238 807 / 242 380 | ×1.59 / ×1.54 |
| `limited-conn-4096` | 907 798 | 1 309 891 | ×1.44 |
| `baseline-4096` | 1 141 979 | 1 639 189 | ×1.44 |
| `baseline-h2-1024` / `-256` | 3 327 227 / 3 416 262 | 4 688 932 / 4 498 827 | ×1.41 / ×1.32 |
| `static-h2-1024` / `-256` 的**常驻内存** | 3.7 GiB / 1.3 GiB | **793 MiB / 189 MiB** | ÷4.8 / ÷7.0 |

**一格没涨的都在这儿，一个不漏**：`latency-10k-1024`（+0.0%）、`echo-ws-4096` / `-512` /
`-16384`（−1.5% / −1.5% / −4.2%）、`latency-500k-8cpu-1024`（−3.8%）、`8gbit-512`（−0.3%）、
`async-db-1024`（+0.8%）、`echo-ws-limited-512` / `-4096`（+2.5% / +3.2%）、
`latency-1m-1024`（+4.7%）。它们各自被**外部因子**钉住 —— `8gbit` 是带宽、`latency-*` 是
往返时延、`latency-500k-8cpu` 按名字只给 8 个 CPU、`async-db` 是 Postgres、`echo-ws` 那三档
是**回显**而不是流水线（见下面归因第 2 条）。这不是"这一版在这几档退步了"。

**这些上涨也不是"换了一台更快的机器"**，这一点有对照：同一装置上被外部因子钉住的那几档
（`8gbit-512`、`latency-10k-1024`、`latency-500k-8cpu-1024`、`async-db-1024`、`echo-ws-512`），
在一轮对一轮的 `cpu_per_req_us`（`= CPU% ÷ rps`，也就是与机器快慢无关的那一半）上全落在
**±4%** 内（第四轮对第三轮第二次：`8gbit-512` −2.2%、`latency-10k-1024` +0.8%、
`latency-500k-8cpu-1024` −0.9%、`async-db-1024` −4.1%、`echo-ws-512` +0.7%）；而上涨的那些档
同一指标掉了 **17% ~ 62%**：

| 上涨的档 | `cpu_per_req_us` 三→四轮 | 二→四轮 |
|---|---:|---:|
| `echo-ws-pipeline-512` | −62.5% | −62.5% |
| `static-h2-1024` | −51.7% | −53.4% |
| `json-tls-4096` | −14.1% | −45.5% |
| `pipelined-4096` | −40.6% | −43.1% |
| `async-32000` | −41.9% | −42.9% |
| `static-tls-1024` | −34.4% | −34.8% |
| `json-comp-4096` | −5.6% | −38.8% |
| `baseline-4096` | −21.6% | −26.7% |
| `baseline-h2-1024` | −19.2% | −21.5% |
| `latency-1m-1024` | −20.5% | −20.4% |
| `limited-conn-4096` | −19.4% | −17.0% |
| `baseline-h2-256` | −21.4% | −17.7% |

（这两列问的不是同一件事，所以两个方向都出现：`baseline-h2-256` 的"二→四"反而比"三→四"
小，是因为它的每请求 CPU 在第二轮→第三轮之间先升了一点（16.61 → 17.39 µs，基数就高了）；
`json-comp-4096` 则相反 —— 它的台阶整个落在第三轮那两次之间，"三→四"只剩 −5.6%。）

**正确性**：42 档的 `5xx` **全是 0**；15 个 `4xx` 全部落在 `production-stack-256`（10 个）与
`production-stack-1024`（5 个），那是编排档故意打的探针。`2xx` 与 `rps × 5 s` 逐档对得上
（`async-32000` 与 `async-db-1024` 两档是 × 10 s，与第二轮同例）。

**16 档是这一轮新订的** —— `baseline-h2c-*`、`gateway-*`、`json-h2c-*`、`production-stack-*`、
`static-h3-64`、`unary-grpc-*` —— 没有第二轮可对照，绝对值在全表里。

全表（42 档，按 `rps` 降序；`相对第二轮` 那一栏是**本报告自己算的**，平台只给绝对值）：

| 档 | rps | 相对第二轮 | `2xx` | `5xx` | CPU | RSS |
|---|---:|---:|---:|---:|---:|---:|
| `echo-ws-pipeline-512` | 30 027 149 | **+176.8%** | 150 135 747 | 0 | 6 641.8% | 79 MiB |
| `echo-ws-pipeline-4096` | 28 938 721 | **+129.1%** | 144 693 608 | 0 | 6 776.1% | 138 MiB |
| `echo-ws-pipeline-16384` | 25 179 465 | **+136.9%** | 125 897 329 | 0 | 6 643.7% | 357 MiB |
| `pipelined-4096` | 6 784 375 | **+87.8%** | 33 921 879 | 0 | 6 360.9% | 148 MiB |
| `baseline-h2c-256` | 4 850 874 | 新订 | 24 399 900 | 0 | 6 055.3% | 82 MiB |
| `baseline-h2c-4096` | 4 702 573 | 新订 | 23 936 100 | 0 | 6 417.1% | 811 MiB |
| `baseline-h2-1024` | 4 688 932 | **+40.9%** | 23 726 000 | 0 | 6 265.0% | 178 MiB |
| `baseline-h2c-1024` | 4 668 853 | 新订 | 23 624 400 | 0 | 6 423.9% | 164 MiB |
| `baseline-h2-256` | 4 498 827 | **+31.7%** | 22 629 100 | 0 | 6 152.2% | 111 MiB |
| `unary-grpc-256` | 3 391 572 | 新订 | 17 059 609 | 0 | 6 123.1% | 145 MiB |
| `unary-grpc-tls-256` | 3 286 145 | 新订 | 16 529 310 | 0 | 6 041.9% | 165 MiB |
| `unary-grpc-1024` | 3 263 606 | 新订 | 16 481 213 | 0 | 6 435.7% | 412 MiB |
| `unary-grpc-tls-1024` | 3 092 506 | 新订 | 15 648 081 | 0 | 6 191.1% | 598 MiB |
| `echo-ws-4096` | 2 844 300 | −1.5% | 14 221 503 | 0 | 6 375.3% | 130 MiB |
| `echo-ws-512` | 2 751 709 | −1.5% | 13 758 545 | 0 | 6 592.8% | 79 MiB |
| `echo-ws-16384` | 2 516 942 | −4.2% | 12 584 713 | 0 | 6 118.9% | 338 MiB |
| `echo-ws-limited-4096` | 1 777 709 | +3.2% | 8 888 547 | 0 | 6 250.1% | 97 MiB |
| `baseline-4096` | 1 639 189 | **+43.5%** | 8 195 949 | 0 | 6 419.0% | 139 MiB |
| `echo-ws-limited-512` | 1 550 796 | +2.5% | 7 753 981 | 0 | 5 899.1% | 90 MiB |
| `async-32000` | 1 513 512 | **+108.7%** | 15 135 122 | 0 | 6 394.1% | 490 MiB |
| `json-h2c-1024` | 1 496 312 | 新订 | 7 556 377 | 0 | 6 387.4% | 298 MiB |
| `json-h2c-4096` | 1 486 566 | 新订 | 7 551 760 | 0 | 6 273.2% | 983 MiB |
| `limited-conn-4096` | 1 309 891 | **+44.3%** | 6 549 456 | 0 | 6 642.4% | 101 MiB |
| `baseline-h3-64` | 1 167 034 | **+2012027.6%** | 5 846 842 | 0 | 4 113.4% | 238 MiB |
| `latency-1m-1024` | 997 940 | +4.7% | 19 961 754 | 0 | 4 538.1% | 81 MiB |
| `json-tls-4096` | 672 436 | **+81.3%** | 3 428 958 | 0 | 6 373.5% | 396 MiB |
| `json-comp-4096` | 325 476 | **+67.4%** | 1 627 384 | 0 | 6 476.7% | 120 MiB |
| `json-comp-16384` | 321 152 | **+67.0%** | 1 605 764 | 0 | 6 091.7% | 162 MiB |
| `latency-500k-8cpu-1024` | 245 021 | −3.8% | 4 902 305 | 0 | 775.7% | 32 MiB |
| `static-h2-1024` | 242 380 | **+54.3%** | 1 221 596 | 0 | 2 463.2% | 793 MiB |
| `static-h2-256` | 238 807 | **+59.4%** | 1 201 201 | 0 | 2 420.0% | 189 MiB |
| `static-tls-1024` | 190 096 | **+65.0%** | 969 434 | 0 | 3 118.3% | 278 MiB |
| `static-h3-64` | 114 206 | 新订 | 572 175 | 0 | 3 085.9% | 472 MiB |
| `gateway-h3-64` | 84 167 | 新订 | 421 679 | 0 | 3 685.2% | 390 MiB |
| `async-db-1024` | 83 890 | +0.8% | 838 902 | 0 | 3 415.7% | 192 MiB |
| `gateway-64-512` | 75 887 | 新订 | 383 234 | 0 | 4 048.1% | 2.5 GiB |
| `gateway-64-1024` | 68 655 | 新订 | 346 709 | 0 | 3 722.8% | 4.8 GiB |
| `gateway-h3-256` | 62 547 | 新订 | 314 616 | 0 | 2 859.1% | 1.5 GiB |
| `production-stack-256` | 53 685 | 新订 | 269 502 | 0 | 3 165.2% | 962 MiB |
| `8gbit-512` | 49 175 | −0.3% | 245 942 | 0 | 319.8% | 128 MiB |
| `production-stack-1024` | 46 274 | 新订 | 234 147 | 0 | 3 301.1% | 2.8 GiB |
| `latency-10k-1024` | 9 983 | +0.0% | 199 683 | 0 | 38.5% | 77 MiB |

**归因**：这一轮涨的东西里，四组能一句话闭合，另一组只到"区间已知"。

1. **`baseline-h3-64` ← `745608c`（1.6.5，短包头按本端 `scid_len` 解 DCID）。** 三次读数把它
   钉死了：第二轮 58、第三轮（`1.6.20-dev`）**1 178 068**、第四轮 1 167 034 —— 也就是修复
   发生在 1.6.20 之前，而 1.6.2~1.6.20 那 43 条提交里动 h3 收包**解码**的只有这一条
   （同段另有 `4aab9e5` 多循环扇出、`c79ec95` h3 上的稍后应答，它们都不解释第二轮那个形状：
   每连接 4.6 个响应、CPU 只有 4.2%，服务端在等而不是在算）。
2. **`echo-ws-pipeline-*` ← `219b0da`（1.6.21，ws 发送队列整批合并）。** 三次读数：
   10 846 084 → **4 300 255**（`1.6.20-dev`）→ 31 022 444（`1.6.22-dev`）。4.30 M 那一格是
   1.6.20，而 `1.6.20-dev → 1.6.22-dev` 之间**只有两条库提交**：`219b0da`（ws）与
   `c8950ae`（JSON 写出器，与 ws 无关）；条目那一侧，`handle_ws` 在四轮之间**逐字节相同**
   （对 `main.cc` 按函数大括号配对切片取哈希，四轮同一个值；`handle_echo` 也是）。
   这条同时是 §4.2 那个"关掉 Nagle 会让 ws 丢掉偶然合并"的现场证词 —— 4.30 M 就是丢掉了的
   样子，31.0 M 是把合并**按批**做回来的样子。顺带解释了为什么 `echo-ws-512/4096/16384`
   反而 −1.5%~−4.2%：那三档是**回显**，本来就没有攒批的余地。
3. **`json-comp-*` / `json-tls-*` ← 库侧 `c8950ae`（1.6.22，键与字符串值改成一次追加，
   每响应 4073 → 1536 次）＋ 条目侧 `af78de0` / `af2807d`（就地序列化、改用框架写出器）。**
   分界很清楚：第二轮 370 872 → 第三轮 **372 754（一格没动）** → 第三轮第二次 568 719 →
   1.7.0 672 436。两个台阶正好是"库的写出器"与"条目改用写出器"，而它们**落在同一段间隔里，
   榜单上分不开**。能分开的是 §4.6 那支只跑序列化的仓外探针：库侧那一段 **1.57~1.59×**，
   与榜单上 +52% 的量级一致。
4. **`static-h2` 的常驻内存 ← `46ba344`（1.6.41，每批最多吐 64 KiB）。** 四次读数：
   3.7 GiB → 2.7 GiB → 3.4 GiB → **793 MiB**，台阶在最后一段；同档 `cpu_per_req_us` 也掉了
   一半（−53.4%）。这一段里条目侧只动过一个静态相关的提交（`7095e92`，静态缓存改在循环
   线程校验），它不碰批大小 —— 而"常驻是批大小吃出来的"正是 `46ba344` 自己的复现判据。
5. **h1 / h2 的高吞吐那一组：区间已知（1.6.23~1.6.51），提交未定。** 这一组
   （`baseline-4096` ×1.44、`pipelined-4096` ×1.88、`async-32000` ×2.09、
   `limited-conn-4096` ×1.44、`baseline-h2-*` ×1.32~1.41）在第二→第三轮**两次**里全落在
   ±7% 内，涨的全部落在最后一段；而这一段的条目侧**只有两个提交**（`bcae45b` 把数据集读成
   扁平数组、`7095e92` 静态缓存），都落在 `/json` 与静态腿上 —— `main.cc` 里
   `handle_baseline11` / `handle_pipeline` / `handle_baseline2` / `handle_baseline2_h3`
   在四轮之间**逐字节没变**（同一种切片哈希；有意思的是 `handle_json` 也四轮没变，变的是它
   调的那几个帮手，可见这个哈希是分得出东西的，不是"什么都相同"）。
   所以差在库里，但候选太多，没有一条能像第 1 条那样一句话闭环：`a9337ef`（1.6.46，
   流水线末条的 `Connection: close`）够不着 `baseline`；h2 交付路径那几条
   （`1d0260b` 每批 `reserve`、`b97c31b` 交付路径收共享视图、`2a622cb` 接管的 body 不再拷）
   只说得上 `baseline-h2`。本机拿 h2load 照形状做 A/B（两臂交替、各 3~5 轮）**复现不出来**：
   `baseline` 两臂落在 0.82×、`pipeline` 1.06×，而臂内离散度有 ±30%（服务端与压测端抢
   同一台 18 核的机器）。这一组在本报告里就记**"库侧、未逐提交归因"**，不编一个理由给它。

#### 第五轮：1.7.2-dev 的读数（2026-10-15T14:21Z，42 档）

**第五轮**（第六轮见下一小节，两轮相隔不到三小时）。被测的那棵树与第四轮**不是同一棵**：

| | 第四轮 | **第五轮** |
|---|---|---|
| 平台的结果提交 | `16c11f7`（2026-10-14T09:27:51Z） | `6fadb86`（2026-10-15T14:21:54Z） |
| 被测的那棵树 | `ae437de` | `a19557f` |
| 库 pin（`ARG LIBUVCPP_REF`） | `6eede33`（`1.6.51-dev`，即 1.7.0） | `8150720`（`1.7.2-dev`） |
| 档数 | 42 | 42 |

第 2 行不是推出来的。平台的 `Benchmark PR` 跑在 `main` 上、checkout 的是 PR 分支，日志里
那一步是 `git checkout --progress --force refs/remotes/pull/1568/head`（运行 38725336959，
2026-10-15T13:57:38Z，随后每一层 `BuildKit` 都在取 `8150720`）；而 **bot 的结果提交是推在
被测那棵树顶上的**，所以「结果提交的父提交」就是被测树 —— `6fadb86^ = a19557f`、
`16c11f7^ = ae437de`，两次都成立，第三轮那两次与第四轮的 pin 也是这么读出来的。

上一小节已经说过，第四轮那个 pin（`6eede33`）与 1.7.0 之间在 `src/` 下只差两处，所以
**第四轮那 42 个数就是 1.7.0 的数**。而从 `v1.7.0` 到第五轮这个 pin 之间，`src/` 下**只有
两条提交**：

```sh
$ git log --oneline v1.7.0..8150720 -- src/
8150720 perf(db): 结果集物化那条路上的分配账 —— 每应答 204.78 → 102.77 次分配（1.7.2-dev）
ebeaa20 perf(webapp): 路径归一化收敛成一个函数，并给它加「什么都不用做」的快路（1.7.1-dev）
```

`ebeaa20` 每条请求都走（本机 callgrind 22 459.6 → 22 032.4 条指令/请求，−1.90%）；
`8150720` 那本账**只走 `/async-db`**。条目这边**只有一条**：`9257623`，而它正是下面
第 2 条要单独说的那件事。

全表（42 档，按 `rps` 降序；`CPU/req` 是 `CPU% ÷ rps`，与机器快慢无关的那一半）：

| 档 | rps | 四→五 | CPU/req | 四→五 | RSS |
|---|---:|---:|---:|---:|---:|
| `echo-ws-pipeline-512` | 31 580 057 | +5.2% | 2.11 µs | −4.6% | 78 MiB |
| `echo-ws-pipeline-4096` | 31 035 676 | +7.2% | 2.06 µs | −12.2% | 134 MiB |
| `echo-ws-pipeline-16384` | 27 866 425 | +10.7% | 2.22 µs | −16.0% | 350 MiB |
| `pipelined-4096` | 7 491 589 | +10.4% | 8.53 µs | −9.0% | 149 MiB |
| `baseline-h2c-256` | 5 752 882 | +18.6% | 10.52 µs | −15.8% | 83 MiB |
| `baseline-h2-256` | 5 552 266 | +23.4% | 11.17 µs | −18.3% | 96 MiB |
| `baseline-h2c-1024` | 5 465 988 | +17.1% | 11.76 µs | −14.5% | 182 MiB |
| `baseline-h2c-4096` | 5 268 627 | +12.0% | 11.68 µs | −14.4% | 790 MiB |
| `baseline-h2-1024` | 5 247 351 | +11.9% | 11.85 µs | −11.3% | 174 MiB |
| `unary-grpc-256` | 3 818 427 | +12.6% | 15.83 µs | −12.3% | 146 MiB |
| `unary-grpc-1024` | 3 760 124 | +15.2% | 17.13 µs | −13.1% | 413 MiB |
| `unary-grpc-tls-256` | 3 720 594 | +13.2% | 16.36 µs | −11.0% | 163 MiB |
| `unary-grpc-tls-1024` | 3 511 060 | +13.5% | 17.04 µs | −14.9% | 598 MiB |
| `echo-ws-4096` | 2 884 971 | +1.4% | 21.74 µs | −3.0% | 134 MiB |
| `echo-ws-512` | 2 833 406 | +3.0% | 23.35 µs | −2.5% | 75 MiB |
| `echo-ws-16384` | 2 577 600 | +2.4% | 23.82 µs | −2.0% | 336 MiB |
| `baseline-4096` | 1 789 003 | +9.1% | 35.33 µs | −9.8% | 139 MiB |
| `echo-ws-limited-4096` | 1 767 053 | −0.6% | 34.76 µs | −1.1% | 93 MiB |
| `json-h2c-1024` | 1 653 574 | +10.5% | 38.49 µs | −9.8% | 303 MiB |
| `echo-ws-limited-512` | 1 600 650 | +3.2% | 36.35 µs | −4.4% | 89 MiB |
| `json-h2c-4096` | 1 580 650 | +6.3% | 39.49 µs | −6.4% | 976 MiB |
| `async-32000` | 1 568 496 | +3.6% | 40.86 µs | −3.3% | 488 MiB |
| `baseline-h3-64` | 1 422 023 | +21.8% | 28.96 µs | −17.8% | 195 MiB |
| `limited-conn-4096` | 1 414 762 | +8.0% | 44.79 µs | −11.7% | 90 MiB |
| `latency-1m-1024` | 998 040 | +0.0% | 43.33 µs | −4.7% | 81 MiB |
| `json-tls-4096` | 724 360 | +7.7% | 87.42 µs | −7.8% | 395 MiB |
| `json-comp-4096` | 335 926 | +3.2% | 186.44 µs | −6.3% | 107 MiB |
| `json-comp-16384` | 330 411 | +2.9% | 196.86 µs | +3.8% | 141 MiB |
| `latency-500k-8cpu-1024` | 264 277 | +7.9% | 29.49 µs | −6.8% | 32 MiB |
| `static-h2-1024` | 252 927 | +4.4% | 102.16 µs | +0.5% | 805 MiB |
| `static-h2-256` | 232 078 | −2.8% | 95.35 µs | −5.9% | 191 MiB |
| `static-tls-1024` | 190 070 | −0.0% | 154.19 µs | −6.0% | 277 MiB |
| `static-h3-64` | 122 803 | +7.5% | 255.61 µs | −5.4% | 788 MiB |
| `async-db-1024` | 98 855 | **+17.8%** | **271.85 µs** | **−33.2%** | 172 MiB |
| `gateway-h3-64` | 84 432 | +0.3% | 408.06 µs | −6.8% | 371 MiB |
| `gateway-64-512` | 77 207 | +1.7% | 495.36 µs | −7.1% | 2.7 GiB |
| `gateway-64-1024` | 68 878 | +0.3% | 526.80 µs | −2.8% | 4.9 GiB |
| `gateway-h3-256` | 62 335 | −0.3% | 441.44 µs | −3.4% | 1.4 GiB |
| `production-stack-256` | 54 088 | +0.8% | 598.65 µs | +1.5% | 928 MiB |
| `8gbit-512` | 49 344 | +0.3% | 60.68 µs | −6.7% | 207 MiB |
| `production-stack-1024` | 48 440 | +4.7% | 709.60 µs | −0.5% | 2.8 GiB |
| `latency-10k-1024` | 9 981 | −0.0% | 36.37 µs | −5.7% | 78 MiB |

**正确性**：`5xx` 依旧是 **42 个 0**。`4xx` 只有 **3 个**，全在编排档的探针上
（`production-stack-256` 2 个、`production-stack-1024` 1 个），比第四轮那 15 个还少。
`2xx` 与窗口的对应关系与第二轮同例：`latency-*` 那三档是 `rps × 20 s`、`async-32000` 与
`async-db-1024` 两档是 `× 10 s`、其余是 `× 5 s` —— 字段里的 `duration` 写的都是 `5s`，
照抄平台字段，不折算。

**读数**：

1. **这一轮几乎全绿，但"绿"里有多少是真信号，要拿对照组量。** 42 档里 32 档 ≥ +1%、
   9 档落在 ±1%（含 `static-tls-1024` 与 `latency-10k-1024` 的 −0.0%）、**只有 1 档跌过
   1%**（`static-h2-256` −2.8%）；`rps` 的中位数 +5.8%、均值 +7.1%，`CPU/req` 的中位数
   −6.8%。但**被外部因子钉住的那几档这一轮自己也动了**：`echo-ws-limited-512` +3.2%、
   `echo-ws-512` +3.0%、`echo-ws-16384` +2.4%、`echo-ws-4096` +1.4%、`8gbit-512` +0.3%、
   `latency-1m-1024` +0.0%、`latency-10k-1024` −0.0%。⇒ **这一轮 ±3% 以内的涨幅读不出东西**。
   与第四轮那次比一比方向：那一轮同样的对照组在 `CPU/req` 那一栏落在 ±4% 内、**正负都有**
   （−4.1% ~ +0.8%），而这一轮这几档在 `rps` 那一栏**齐刷刷地全为正**。所以这一轮有一个
   整体往上抬的偏置，不能拿"对照组没动"那句老话套。这一轮全表能"一句话闭合"的只有下面
   第 2 条，其余各条都只能读到"形状"。

2. **`async-db-1024` 的 −33.2% 是 `9257623` 的量 —— 而那条改动已经不在树上了。**
   `CPU/req` 407.2 → **271.85 µs**、rps 83 890 → **98 855**、平均延迟 11.77 → 9.88 ms、
   p99 41.7 → 37.7 ms。全表没有第二格涨得这么多，而它涨的原因是**单一且已知的**：
   `9257623` 把 `/async-db` 从「每行建一个 DOM 再 `dump()`」换成 `uvcpp_json_writer`
   流式写出 —— 该提交自己的判据是同一台本机上 callgrind **781 765 → 343 665 条指令/请求
   （−56.04%，≈262 → 115 µs 用户态 CPU）**，两处大头是 `parse_tags` + 那次 `dump()`
   （占该档客户端 CPU 的 13.8%）与每应答 200 次按列名的查找（12.4%）。
   **这正是本报告写作时被撤回的那一条**：维护者在 2026-10-15 指出 `mode: standard` 的条目
   不能用替代序列化器（`tuned.md` 把 "Alternative JSON serializers" 列在 Tuned 栏下），
   条目随后改回 nlohmann DOM + `resp.json()`。所以这一格是**平台的实测替我们算出"合规值
   多少钱"**：把 DOM 换回来，这一档的每请求 CPU 大致要回到 400 µs 那一档去。
   同一个区间里的 `8150720` 解释不了这 135 µs —— 它省的是 102 次 `malloc`/应答，按本机的
   分配账换算是**个位数 µs**。（async-db 是 Reference-only、不进合成分；这一格的全部意义
   就在它自己的 `CPU/req` 那一栏上。）

3. **静态腿停住了，同时它那条"每请求一次线程池往返"的归因被这一轮证伪。**
   `static-h2-1024` +4.4%、`static-h2-256` −2.8%、`static-tls-1024` −0.0%、
   `static-h3-64` +7.5% —— 第四轮那次 +52%（159 233 → 242 380）之后，它停在那儿了。
   这一轮走静态处理器的那几档的 `CPU` 是 2 212.8% ~ 3 139.0%，也就是**封在 22~31 核**；
   而 `json-tls-4096` 用掉了 **63.3 核**（6 332.4%），它的每请求 CPU 却**不比静态档高**
   （87.42 µs 对 `static-h2-256` 的 95.35 µs）。同样量级的每请求成本、一半的核数
   ⇒ 卡住静态档的是**并行度**，不是每请求开销。于是那个上限曾被归到静态路上每请求一次的
   线程池往返上，对应的修法是
   `o.precompressed = true` + `o.revalidate = LOOP_STAT`。**把被测树的那两行读出来就知道
   不是它**：`precompressed` 早在第三轮那棵树（`af2807d`，2026-10-13）里就有，`revalidate`
   那行在第四轮那棵树（`ae437de`）里 —— 第四轮那 +52% 本身就落在它们落地的那一段里，
   而**第五轮没有任何新东西可吃**。⇒ 那个 ~25-31 核的上限不是这两行能解释的，得重新归因。
   （判据就是 `git show <被测树>:frameworks/libuvcpp/main.cc | grep o.precompressed o.revalidate`
   —— 一行命令，谁都可以复核。）

4. **超出库侧改动能解释的那一组，照旧记"库侧、区间已知、提交未定"。**
   `baseline-h2-256` +23.4%、`baseline-h3-64` +21.8%、`baseline-h2c-256` +18.6%、
   `baseline-h2c-1024` +17.1%、`unary-grpc-1024` +15.2% —— 这些档的 `CPU` 那一栏两轮几乎
   逐格相同（6 152→6 202%、4 113→4 118%、6 055→6 050%、6 424→6 427%、6 436→6 440%），
   也就是**同一个 CPU 天花板下多出来了 12~23% 的吞吐**。这个区间里只有一条 −1.90% 的改动，
   差一个数量级，解释不了 —— 与第四轮那组同样的处理：**记形状，不编理由**。
   （对照组那几档只动了 +0.0% ~ +3.2%，够不着这 12~23%，所以它不是"换了台更快的机器"；
   剩下可能是这一轮饱和档上调度/装箱的状态，本机复现不了，如实留白。）

5. **两处内存离群，而且是双峰而不是单调爬。** `static-h3-64` 的常驻
   841 → 843 → **472** → 788 MiB、`8gbit-512` 206 → 129 → 128 → **207 MiB** ——
   这两档在四轮里都在两个值之间来回跳，而它们的 `rps` 分别只动了 +7.5% / +0.3%。
   本报告不编归因；被 `46ba344` 钉住的是 `static-h2` 那条线（805 / 191 MiB，+1.5% / +1.1%）。

6. **`latency-500k-8cpu-1024` 差它的目标一半，两轮同形。** 目标 500 000 rps，给到 264 277
   （`rate_ratio` 0.5286，第四轮 0.49），p99 **9.97 s**、平均 4.65 s。它的 `CPU` 是 779.4%
   —— 这一档按名字只给 8 个 CPU，也就是**把这 8 个核吃到了 97%**，而它的 `CPU/req`
   29.49 µs 在全表里算低的。⇒ 这一档的差距是"8 个核不够"，不是每请求开销。

#### 第六轮：1.7.2-dev 的读数（2026-10-15T17:03Z，42 档）

**第六轮在第五轮之后不到三小时**，被测的树与 pin 都换了。这一轮**条目那边动了四处，
而四处都不是性能调优** —— 是把不合规的东西换回框架自己的东西（JSON 写出器、边），
以及把框架自己的响应压缩打开。**读完那张表之前必须先知道这件事**，否则会把它们
读成库的回归；下面第 1、2、6 条逐条对。

| | 第五轮 | **第六轮** |
|---|---|---|
| 平台的结果提交 | `6fadb86`（2026-10-15T14:21:54Z） | `16e6e49`（2026-10-15T17:03:25Z） |
| 被测的那棵树 | `a19557f` | `9b0c2e2` |
| 库 pin（`ARG LIBUVCPP_REF`） | `8150720`（`1.7.2-dev`） | `02ae418`（`1.7.2-dev`） |
| 档数 | 42 | 42 |

```sh
$ git log --oneline a19557f..9b0c2e2 -- frameworks/libuvcpp/
9b0c2e2 Move the pin to 02ae418 (1.7.2-dev), four code commits past 8150720
9964faf Answer the JSON profiles with the framework's standard serializer
581ca9e Bind the nginx edges to the two loopback addresses, not the wildcard
3b902d8 Serve gateway-64 and production-stack from a stock nginx edge
c1be8fa Build the brotli encoder into the entry

$ git log --oneline 8150720..02ae418 -- src/
02ae418 perf(webapp): resp.json() 的应答体不再多拷一遍 —— 每应答 −1.0000 次 memcpy / −8 397 字节
370d6ef perf(quic): 发送队列每块的容量按「这次要写多少」定 —— h3 每请求分配字节 −89.6%
3cbfc9a perf(quic): 一个数据报装多条流 —— sendmsg 从 1.03 次/请求降到 0.05
e716010 perf(db): 没装日志回调时不再构造那一行日志 —— 每应答 −3.96 次分配
```

时间戳上有个坑：条目的提交带 `+08:00`。`9964faf` 写作
`2026-10-15T23:28:58+08:00`，换成 UTC 是 **15:28:58Z** —— **早于**六轮那棵树
`9b0c2e2`（16:30:33Z）。所以「用回框架标准序列化器」那个改动**是在六轮里的**，
不是六轮之后才落地的；`git merge-base --is-ancestor 9964faf 9b0c2e2` 也返回真。

全表（42 档，按 `rps` 降序；`CPU/req` 是 `CPU% ÷ rps`）：

| 档 | rps | 五→六 | CPU/req | 五→六 | RSS |
|---|---:|---:|---:|---:|---:|
| `echo-ws-pipeline-4096` | 31 601 507 | +1.8% | 2.03 µs | −1.3% | 136 MiB |
| `echo-ws-pipeline-512` | 30 734 953 | −2.7% | 2.17 µs | +2.6% | 79 MiB |
| `echo-ws-pipeline-16384` | 28 207 107 | +1.2% | 2.23 µs | +0.4% | 358 MiB |
| `pipelined-4096` | 7 326 797 | −2.2% | 9.07 µs | +6.3% | 153 MiB |
| `baseline-h2c-256` | 5 680 497 | −1.3% | 10.90 µs | +3.6% | 83 MiB |
| `baseline-h2c-1024` | 5 552 958 | +1.6% | 11.41 µs | −3.0% | 144 MiB |
| `baseline-h2-1024` | 5 435 683 | +3.6% | 11.39 µs | −3.9% | 174 MiB |
| `baseline-h2-256` | 5 425 606 | −2.3% | 11.70 µs | +4.7% | 112 MiB |
| `baseline-h2c-4096` | 5 316 594 | +0.9% | 12.00 µs | +2.8% | 795 MiB |
| `unary-grpc-256` | 3 827 901 | +0.2% | 15.61 µs | −1.4% | 145 MiB |
| `unary-grpc-1024` | 3 725 148 | −0.9% | 17.29 µs | +0.9% | 414 MiB |
| `unary-grpc-tls-256` | 3 695 725 | −0.7% | 16.61 µs | +1.5% | 163 MiB |
| `unary-grpc-tls-1024` | 3 533 276 | +0.6% | 17.44 µs | +2.3% | 594 MiB |
| `baseline-h3-64` | 3 030 258 | +113.1% | 11.39 µs | −60.7% | 134 MiB |
| `echo-ws-4096` | 2 929 961 | +1.6% | 21.68 µs | −0.3% | 130 MiB |
| `echo-ws-512` | 2 851 128 | +0.6% | 22.96 µs | −1.7% | 78 MiB |
| `echo-ws-16384` | 2 611 015 | +1.3% | 23.36 µs | −1.9% | 329 MiB |
| `echo-ws-limited-4096` | 1 795 680 | +1.6% | 34.42 µs | −1.0% | 95 MiB |
| `baseline-4096` | 1 708 528 | −4.5% | 39.30 µs | +11.2% | 141 MiB |
| `echo-ws-limited-512` | 1 593 577 | −0.4% | 36.92 µs | +1.6% | 93 MiB |
| `async-32000` | 1 533 457 | −2.2% | 40.52 µs | −0.8% | 490 MiB |
| `limited-conn-4096` | 1 385 176 | −2.1% | 45.40 µs | +1.4% | 88 MiB |
| `latency-1m-1024` | 997 684 | −0.0% | 38.86 µs | −2.2% | 81 MiB |
| `json-h2c-1024` | 656 607 | −60.3% | 96.61 µs | +151.0% | 306 MiB |
| `json-h2c-4096` | 634 021 | −59.9% | 98.43 µs | +149.3% | 1.0 GiB |
| `json-tls-4096` | 403 673 | −44.3% | 153.84 µs | +76.0% | 411 MiB |
| `latency-500k-8cpu-1024` | 264 320 | +0.0% | 30.18 µs | −0.0% | 32 MiB |
| `production-stack-256` | 258 622 | +378.2% | 186.49 µs | −68.8% | 1.2 GiB |
| `static-h2-256` | 242 138 | +4.3% | 90.08 µs | −5.5% | 187 MiB |
| `static-h2-1024` | 239 512 | −5.3% | 95.44 µs | −6.6% | 511 MiB |
| `production-stack-1024` | 204 370 | +321.9% | 206.42 µs | −70.9% | 2.0 GiB |
| `static-tls-1024` | 198 927 | +4.7% | 154.70 µs | +0.3% | 409 MiB |
| `gateway-64-512` | 122 364 | +58.5% | 398.05 µs | −19.6% | 1.4 GiB |
| `gateway-64-1024` | 120 098 | +74.4% | 426.25 µs | −19.1% | 2.0 GiB |
| `static-h3-64` | 113 382 | −7.7% | 262.90 µs | +2.9% | 272 MiB |
| `async-db-1024` | 87 341 | −11.6% | 387.20 µs | +42.4% | 174 MiB |
| `gateway-h3-64` | 80 155 | −5.1% | 571.08 µs | +40.0% | 446 MiB |
| `gateway-h3-256` | 62 641 | +0.5% | 560.18 µs | +26.9% | 1.4 GiB |
| `json-comp-16384` | 59 118 | −82.1% | 1036.49 µs | +426.5% | 140 MiB |
| `json-comp-4096` | 50 389 | −85.0% | 1238.17 µs | +564.1% | 131 MiB |
| `8gbit-512` | 49 371 | +0.1% | 65.63 µs | −0.3% | 166 MiB |
| `latency-10k-1024` | 9 982 | +0.0% | 37.85 µs | +0.4% | 76 MiB |

**正确性**：42 档全部有数，`5xx` **0**、`4xx` **0**（第五轮 `4xx` 是 3）。

1. **`json-*` 三档换回标准序列化器：每条请求 +58 ~ +66 µs，三档同量级。**
   `9964faf` 把 `/json`、`/public/json/:count` 与 `/async-db` 从 `uvcpp_json_writer`
   换回框架的标准序列化 —— 每请求现建一棵 `nlohmann::json` 的 DOM，交给 `resp.json()`。

   | 档 | 五 rps | 六 rps | rps | CPU/req 五 → 六 |
   |---|---:|---:|---:|---:|
   | `json-h2c-1024` | 1 653 574 | 656 607 | −60.3% | 38.5 → 96.6 µs（**+58.1**） |
   | `json-h2c-4096` | 1 580 650 | 634 021 | −59.9% | 39.5 → 98.4 µs（**+58.9**） |
   | `json-tls-4096` | 724 360 | 403 673 | −44.3% | 87.4 → 153.8 µs（**+66.4**） |

   三档加的都是 58 ~ 66 µs，**而加完之后三档仍然吃满 62 ~ 63 个核**（62.4 / 62.4 / 62.1）。
   核数没掉、吞吐按同一个比例掉 ⇒ 这是"每请求的活变多了"，不是"少用了核"。量级也对得上
   条目自己在本机量到的那一笔（`9964faf` 的信息里：`/json/50?m=6`、6 个钉住的核上，
   写出器 63.2 µs、DOM 176.0 µs）。⇒ **这三档不是坏了，是换掉不合规的写出器之后应付的价。**

2. **`json-comp` 是唯一同时换了序列化器与编码器的档，它的账比上面那三档大一个数量级。**
   `json-comp-4096` 335 926 → 50 389（−85.0%），`CPU/req` 186.4 → **1 238.2 µs**（+1 051.7）；
   `json-comp-16384` 330 411 → 59 118（−82.1%），196.9 → 1 036.5（+839.6）。
   两档同样吃满 62 个核（62.4 / 61.3）—— 同一条"核数没掉、每请求变贵"的形状。

   它与上面那三档的差别只有一处，而且是**两条提交叠出来的**：

   - 它也吃 `9964faf`（`/json` 是同一个处理函数）⇒ 那笔应当是 +58 µs；
   - **它的客户端报 `Accept-Encoding: gzip, br`，而六轮第一次把 brotli 编进了条目**
     （`c1be8fa`，`-DUVCPP_ENABLE_BROTLI=ON`）。`profiles.sh` 里 `json-comp` 走的是
     `requests/json-gzip-25.raw` / `-40` / `-50` 三个**捕获好的请求文件**，逐字节是
     `GET /json/50?m=6` + `Host: localhost:8080` + **`Accept-Encoding: gzip, br`**；
     而 `parse_accept_encoding()` 在 q 相等时按 `rank_of()` 取小者，`BROTLI = 0 < GZIP = 1`
     ⇒ **协商结果从 gzip 变成了 br**。第五轮那棵树的 `Dockerfile` 里这个开关是关的
     （原注释："the platform's flag set above builds neither"），所以第五轮发的是 gzip。

   ⇒ 这一档的 +1 051.7 µs 里只有约 58 µs 是序列化器，**其余约 990 µs 是编码器换人**。

3. **brotli 这笔钱本机量得到，但本机的倍率只有 ~1.9×，够不到平台那 5.06×。**
   本机同一份条目、同一条请求（`/json/50?m=6`）、服务端钉在 8-15，**只换 `Accept-Encoding`**：

   | 臂 | minor fault | 每请求 CPU |
   |---|---:|---:|
   | `gzip` | 0.00 次/请求 | 257.0 µs |
   | `br` | **72.43 次/请求** | 508.0 µs |

   把服务端核数从 8 降到 4、2，把并发从 64 提到 512、2 048 —— **本机能拧的旋钮都拧了，
   这个比值是 1.77 / 1.94 / 1.94 / 1.98 / 1.90 / 1.91，是个常数 ~1.9×**。
   折到平台上：`(186.4 + 58.1) × 1.9 ≈ 465 µs`，**实测 1 238 µs —— 还剩约 774 µs（2.7×）
   本机复现不出来**。这一条**如实记成未解释**，不编理由：核数与并发两条缩放本机都量过，
   都是平的，所以"平台核多"解释不了它。能确认的只有**方向**：多出来的钱全在 brotli 这条路上。

4. **brotli 这笔钱是什么：每请求重建一次编码器状态，glibc 把内存还给内核，下一个请求再缺页拿回来。**
   这一段全是本机的确定性读数，与平台无关：

   - 库自己的注释（`src/web/uvcpp_http_compress.cpp`，zlib 那个 thread-local `deflate_slot`
     旁边）已经把同一类坑写死了：每请求 256 KB 的分配落在 glibc 的 128 KB `mmap` 阈值之上，
     于是走 `mmap`/`munmap`，那要拿内核的地址空间锁、还会打掉别的核的 TLB —— 在
     `json-comp` 那一档上量到 **42 000 → 15 800 rps**。紧接一句是「**这一套在 brotli 上做不到**」，
     理由是 brotli 根本没有 `BrotliEncoderReset()`。⇒ 这条路每请求
     `BrotliEncoderCreateInstance()` / `DestroyInstance()` 一次。
   - 本机一个 ~8 445 B 的正文：br 一共要 **927 249 B**，其中**两块 ≥ 256 KiB**（在阈值之上）；
     同一份正文走 gzip 是 497 469 B，最大的块全落在 64–128 KiB 桶里。
   - 服务端实测：br **860 673.6 B/请求**、**72.20 次缺页/请求**；gzip 162 348.6 B/请求、
     **0.00 次缺页/请求** —— 同一台服务器、同一条请求，只有 `Accept-Encoding` 不同，
     3 次重复与 2 万次请求之内都稳定。
   - **因果**：逼着 glibc 不还内存，缺页就没了 ——

     | 环境 | 缺页/请求 | CPU/请求 |
     |---|---:|---:|
     | `br` 默认 | 72.66 | 522.5 µs |
     | `br` 只抬 `MALLOC_MMAP_THRESHOLD_` | 78.63 | 513.5 µs |
     | `br` 抬 `MALLOC_MMAP_THRESHOLD_` + `MALLOC_TRIM_THRESHOLD_` | **0.00** | **385.5 µs** |
     | `gzip` 默认 / 同上两个变量 | 0.00 / 0.00 | 261.0 / 262.5 µs |

     只抬 `mmap` 阈值没用（72.66 → 78.63，反而多一点）⇒ 那 700 KB 本来就走堆（glibc 的
     `mmap` 阈值是**动态**的，见过一次 `munmap` 之后自己就升上去），**还回去的是堆顶那次
     `trim`**。两个都抬起来，缺页归零、CPU **−26%**；而 gzip 那一臂两个配置下一动不动
     （它的内核是复用的 thread-local，压根不分配）。

   ⇒ **这是一处真实的库内缺陷，修法是确定的**：给 `BrotliEncoderCreateInstance()` 传一对
   自己的分配/释放钩子（brotli 的 `brotli_alloc_func` / `brotli_free_func`），在里面按大小
   做线程本地回收。**输出字节不可能变**（brotli 的编码结果与内存从哪来无关），本机的判据是
   确定的：缺页 72.20 → 0、每请求 CPU −26%。

5. **`baseline-h3-64`：两条 QUIC 提交，+113.1%，是本轮库侧最大的一次涨。**
   1 422 023 → **3 030 258** rps（+113.1%），`CPU/req` 29.0 → **11.4 µs**（−60.7%），
   核数 41.2 → 34.5。这条路上吃到两条：`3cbfc9a`（一个数据报装多条流，
   `sendmsg` 1.0316 → 0.0428 次/请求）与 `370d6ef`（发送队列每块的容量按这次要写多少定，
   每请求分配字节 −89.6%）。**涨的是每请求成本那一半**：每请求便宜了 60.7%，核数还少了。

6. **`gateway-64-*` 与 `production-stack-*`：边从 Caddy 换成 stock nginx。**
   `3b902d8` 把这两族的边换成了 `nginx:1.27-alpine`，`581ca9e` 把边的监听从通配绑到两个
   回环地址（通配的 `listen 8443` 会跟条目那 64 个通配 socket 进同一个 SO_REUSEPORT 组）。

   | 档 | 五 rps | 六 rps | rps | CPU/req 五 → 六 | 核 五 → 六 |
   |---|---:|---:|---:|---:|---:|
   | `gateway-64-512` | 77 207 | 122 364 | +58.5% | 495.4 → 398.1 | 38.2 → 48.7 |
   | `gateway-64-1024` | 68 878 | 120 098 | +74.4% | 526.8 → 426.3 | 36.3 → 51.2 |
   | `production-stack-256` | 54 088 | 258 622 | **+378.2%** | 598.7 → 186.5 | 32.4 → 48.2 |
   | `production-stack-1024` | 48 440 | 204 370 | **+321.9%** | 709.6 → 206.4 | 34.4 → 42.2 |

   四档同一条形状：**`CPU/req` 掉、用掉的核数涨**。`production-stack` 那两档的 `CPU/req`
   掉到三分之一 ⇒ **第五轮那两档的瓶颈在 Caddy**（它自己的 CPU 记在条目的 cgroup 里）。
   这里要注意口径：这不是库的功劳，是边的替换。

7. **`async-db-1024` 也吃 `9964faf`，−11.6%。** 98 855 → 87 341 rps，
   `CPU/req` 271.9 → 387.2 µs（+115.3），核数 26.9 → **33.8**。与 `json-h2c` 那笔同源
   （换回标准序列化器），只是它的 DOM 更大（50 行 × 9 列）。**这一档是 Reference-only、
   对合成奖牌分贡献 0** —— 这条 −11.6% 只体现在 `cpu_per_req_us` 这一栏上。

8. **`static-h2` 两档持平（+4.3% / −5.3%）。** 静态腿这一轮**没有任何改动**（它那段
   `precompressed` / `revalidate` 早在第三、第四轮那两棵树里就落了地，见上一小节第 3 条），
   所以持平是预期的。走静态处理器的那几档这一轮仍在 **21.8 ~ 22.9 核**，与第五轮那个
   ~25-31 核的上限同形；**那个上限的归因仍是待办**，这一轮没有给出新信息。

9. **`baseline-4096` 是唯一一处小幅回退。** 1 789 003 → 1 708 528（−4.5%），
   `CPU/req` 35.3 → 39.3（+11.2%），核数 63.2 → 67.1。这一档本轮**没有任何针对它的改动**，
   而 −4.5% 刚好落在第五轮那组外部漂移（1.4% ~ 3.2%）之外一点点。**记形状，不编理由。**

#### 第七轮：1.7.2-dev 的读数（2026-10-16T08:58Z，42 档）

**这一轮把前几轮埋在静态腿里的那笔账兑现了。** 三件事打在互不相同的档上（只有 `gateway-64`
那一族同时吃到两件，见下面第 4 条）：

1. **库侧**：静态处理器热路上最后那把**跨循环的全局锁**换成每条循环的前台副本
   （`1f6a8fb`，就是 §4.18 那一刀的修法）—— **这是它第一次进平台读数**，第六轮的 pin
   `02ae418` 早于它。
2. **条目侧**：h3 那条**另一份**静态实现（`uvcpp_static_server`）的缓存校验搬回循环线程
   （`ea38462`）。h1/h2 那条腿从第三/第四轮起就带着这个选项，h3 那条腿从有这个选项起
   **一直没设过**（见 §4.8）。
3. **条目侧**：把上一轮为 `json-comp` 编进来的 brotli 又编了回去（`16cba4a`，`c1be8fa`
   的反操作）。

| | 第六轮 | **第七轮** |
|---|---|---|
| 平台的结果提交 | `16e6e49`（2026-10-15T17:03:25Z） | `69ff884`（2026-10-16T08:58:58Z） |
| 被测的那棵树 | `9b0c2e2` | `d4c8625` |
| 库 pin（`ARG LIBUVCPP_REF`） | `02ae418`（`1.7.2-dev`） | `1f6a8fb`（`1.7.2-dev`） |
| 档数 | 42 | 42 |

```sh
$ git log --oneline 9b0c2e2..d4c8625 -- frameworks/libuvcpp/
c1f38b7 Correct the commit the h1/h2 static legs went on `LOOP_STAT` at
a501776 Move the pin to 1f6a8fb (1.7.2-dev), three commits past 02ae418
ea38462 Give the h3 static leg the cache-validation thread the h1/h2 legs have
16cba4a Build the brotli encoder back out of the entry

$ git log --oneline 02ae418..1f6a8fb -- src/
1f6a8fb perf(webapp): 静态腿 LOOP_STAT 档的解析记忆与缓存比对改走每条循环的前台副本
0aaa415 perf(web): brotli 编码器状态要的内存改从线程本地竞技场里发
```

（pin 从 `02ae418` 往前走了**三**笔，第三笔 `b7cae85` 是文档提交，所以 `-- src/` 只有两笔。而 `0aaa415`
这一笔在本轮**是惰性的**：它改的是 brotli 编码器状态的内存来路，而 `16cba4a` 已经把那个
编码器整个编出了条目 —— 这一轮量不到它。）

全表（42 档，按 `rps` 降序；`CPU/req` 是 `CPU% ÷ rps`，与平台自己给的
`cpu_per_req_us` 逐格相同）：

| 档 | rps | 六→七 | CPU/req | 六→七 | RSS |
|---|---:|---:|---:|---:|---:|
| `echo-ws-pipeline-512` | 30 670 502 | −0.2% | 2.17 µs | +0.0% | 78 MiB |
| `echo-ws-pipeline-4096` | 29 440 675 | −6.8% | 2.31 µs | +13.8% | 137 MiB |
| `echo-ws-pipeline-16384` | 28 115 031 | −0.3% | 2.20 µs | −1.0% | 350 MiB |
| `pipelined-4096` | 7 502 178 | +2.4% | 8.44 µs | −6.9% | 149 MiB |
| `baseline-h2c-256` | 5 550 996 | −2.3% | 10.94 µs | +0.4% | 83 MiB |
| `baseline-h2-1024` | 5 327 411 | −2.0% | 11.56 µs | +1.5% | 172 MiB |
| `baseline-h2-256` | 5 304 166 | −2.2% | 11.53 µs | −1.4% | 96 MiB |
| `baseline-h2c-1024` | 5 280 019 | −4.9% | 11.99 µs | +5.1% | 160 MiB |
| `baseline-h2c-4096` | 5 031 650 | −5.4% | 12.75 µs | +6.3% | 798 MiB |
| `unary-grpc-256` | 3 798 244 | −0.8% | 16.38 µs | +5.0% | 148 MiB |
| `unary-grpc-tls-256` | 3 681 783 | −0.4% | 16.80 µs | +1.1% | 163 MiB |
| `unary-grpc-1024` | 3 667 663 | −1.5% | 17.30 µs | +0.1% | 423 MiB |
| `unary-grpc-tls-1024` | 3 444 335 | −2.5% | 18.70 µs | +7.3% | 520 MiB |
| `baseline-h3-64` | 3 077 350 | +1.6% | 11.88 µs | +4.3% | 133 MiB |
| `echo-ws-512` | 2 849 239 | −0.1% | 23.63 µs | +2.9% | 77 MiB |
| `echo-ws-4096` | 2 838 290 | −3.1% | 22.60 µs | +4.3% | 132 MiB |
| `echo-ws-16384` | 2 565 508 | −1.7% | 25.74 µs | +10.2% | 335 MiB |
| `echo-ws-limited-4096` | 1 778 136 | −1.0% | 35.37 µs | +2.8% | 94 MiB |
| `baseline-4096` | 1 732 068 | +1.4% | 36.50 µs | −7.1% | 140 MiB |
| `echo-ws-limited-512` | 1 574 604 | −1.2% | 38.27 µs | +3.7% | 92 MiB |
| `async-32000` | 1 541 917 | +0.6% | 39.81 µs | −1.7% | 488 MiB |
| `limited-conn-4096` | 1 414 686 | +2.1% | 44.50 µs | −2.0% | 92 MiB |
| `latency-1m-1024` | 997 811 | +0.0% | 40.03 µs | +3.0% | 81 MiB |
| `static-h2-256` | 802 360 | +231.4% | 80.26 µs | −10.9% | 245 MiB |
| `json-h2c-1024` | 655 129 | −0.2% | 98.04 µs | +1.5% | 303 MiB |
| `json-h2c-4096` | 639 897 | +0.9% | 100.53 µs | +2.1% | 1 016 MiB |
| `static-tls-1024` | 568 833 | +186.0% | 113.69 µs | −26.5% | 274 MiB |
| `static-h2-1024` | 547 363 | +128.5% | 117.34 µs | +22.9% | 659 MiB |
| `json-tls-4096` | 399 878 | −0.9% | 163.24 µs | +6.1% | 662 MiB |
| `latency-500k-8cpu-1024` | 260 201 | −1.6% | 30.65 µs | +1.6% | 33 MiB |
| `production-stack-256` | 256 484 | −0.8% | 188.22 µs | +0.9% | 1.2 GiB |
| `static-h3-64` | 239 028 | +110.8% | 175.42 µs | −33.3% | 302 MiB |
| `production-stack-1024` | 208 224 | +1.9% | 206.12 µs | −0.1% | 2.0 GiB |
| `json-comp-4096` | 199 935 | +296.8% | 313.79 µs | −74.7% | 114 MiB |
| `gateway-64-512` | 199 358 | +62.9% | 272.46 µs | −31.6% | 1.5 GiB |
| `json-comp-16384` | 197 549 | +234.2% | 308.74 µs | −70.2% | 120 MiB |
| `gateway-64-1024` | 196 673 | +63.8% | 266.70 µs | −37.4% | 1.8 GiB |
| `async-db-1024` | 86 449 | −1.0% | 391.97 µs | +1.2% | 176 MiB |
| `gateway-h3-64` | 83 510 | +4.2% | 454.65 µs | −20.4% | 431 MiB |
| `gateway-h3-256` | 61 721 | −1.5% | 478.69 µs | −14.5% | 1.4 GiB |
| `8gbit-512` | 49 306 | −0.1% | 65.52 µs | −0.2% | 208 MiB |
| `latency-10k-1024` | 9 980 | −0.0% | 37.34 µs | −1.3% | 77 MiB |

**正确性**：42 档全部有数，`5xx` **0**、`4xx` **0**。

1. **静态腿的并行度天花板这一轮被拿掉了 —— 全表最大的三次涨，而且形状就是 §4.18 预测的
   那一个。** 三档走静态处理器的 h1/h2 档，`rps` 与**用掉的核数**成对地动：

   | 档 | 六 rps | 七 rps | rps | 六 核 | 七 核 | CPU/req 六 → 七 |
   |---|---:|---:|---:|---:|---:|---:|
   | `static-h2-256` | 242 138 | **802 360** | +231.4% | 21.8 | **64.4** | 90.08 → 80.26 |
   | `static-h2-1024` | 239 512 | **547 363** | +128.5% | 22.9 | **64.2** | 95.44 → 117.34 |
   | `static-tls-1024` | 198 927 | **568 833** | +186.0% | 30.8 | **64.7** | 154.70 → 113.69 |

   三档**同一条形状**：第六轮它们各自用掉二十来到三十个核（而同一轮 `json-tls-4096`
   用了 **63.73 核**，且它的 `CPU/req` 比它们**高**）—— 也就是**多核也快不起来**；这一轮
   三档全部顶到 cpuset 的 64 个逻辑核上。`static-h2-256` 那一格是本报告里第一次出现
   80 万 rps 量级的档。

   §4.18 那个模型对得上：那把锁的持有时长给的吞吐上限是 **0.30~0.46 M rps**，而第六轮
   实测 242 138 / 239 512 —— **正好压在预测的下沿**。本机只量到 +19.6%（9 核上那把锁
   本来就不紧），§4.18 当时写的是"平台的效应只能按 `1/持有` 那个模型预测，本机不作验收"
   —— **这一轮就是那次验收**，而且是按最有利的方式过的。

   一句必须跟着说的口径：**`static-tls-1024` 是 `scored: false`**（`site/leaderboard/
   data.js` 的 `profiles` 里 `static-tls` 那一项），所以它那 +186.0% **不进合成分**。
   它在这里的价值只有一个：**第三个同形的样本**，把"这是那把锁"钉得更死。

2. **h3 那条静态腿是另一份实现（`ea38462`），+110.8%，而且它是条目侧一行。**
   113 382 → **239 028**，`CPU/req` 262.90 → **175.42**（−33.3%），核数 29.8 → 41.9
   （**仍没吃满**）。这一格与库无关，但它与第 1 条修的是**同一件事的两半**：h1/h2 那条腿
   从第三轮起就带着 `revalidate = LOOP_STAT`，而 h3 只能挂 `uvcpp_static_server`
   —— 那是**另一份实现、选项要设两遍**（§4.8 就是这个坑），它从有这个选项起一直没设过，
   于是每个 `static-h3` 请求都白投一次线程池往返。**一条 `set_revalidate` 换 2.1 倍。**

3. **`json-comp` 两档回到 gzip 的水位（+296.8% / +234.2%），但**没有**回到第五轮。**
   335 926 / 330 411（五）→ 50 389 / 59 118（六）→ **199 935 / 197 549**（七），
   也就是七轮是五轮的 **59.5% / 59.8%**。`CPU/req`：
   186.4 / 196.9（五）→ 1 238.2 / 1 036.5（六）→ **313.8 / 308.7**（七）。拆两笔：

   | | 五 → 六 | 六 → 七 | 五 → 七（剩下的） |
   |---|---:|---:|---:|
   | `json-comp-4096` | +1 051.8 µs | −924.4 µs | **+127.4 µs** |
   | `json-comp-16384` | +839.6 µs | −727.8 µs | **+111.8 µs** |

   `16cba4a` 把 gzip 与 br 的差收回去（约 166 / 85 µs），**剩下的 127.4 / 111.8 µs 是
   第六轮换回标准序列化器那笔（`9964faf`）—— 这一轮没有再欠新的**。同理，这一档是按
   **每应答字节数**计分的，br 走了 ⇒ 字节那一项也回到 gzip 的。

4. **`gateway-64` 两档 +62.9% / +63.8%：那是混载，被本轮第 1、3 条同时推起来的，
   不是第三件独立的事。** `requests/gateway-64-uris.txt` 那 20 条 URL 是
   **6 条 `/static/*` + 4 条 `/baseline2` + 7 条 `/json/*` + 3 条 `/async-db`**：
   前 6 条吃 `1f6a8fb`，那 7 条 `/json/*` 吃 `16cba4a`。形状也对得上 ——
   `CPU/req` 398.05 → 272.46（−31.6%）与 426.25 → 266.70（−37.4%），
   核数 48.7 → **54.3** 与 51.2 → **52.5**。（`/async-db` 那 3 条没动：
   `async-db-1024` 自己 −1.0%。）

5. **`baseline-h2*` / `baseline-h2c*` 五档成片回退（−2.0% ~ −5.4%），本轮对它们没有任何
   改动。** `baseline-h2-256` −2.2%、`baseline-h2-1024` −2.0%、`baseline-h2c-256` −2.3%、
   `baseline-h2c-1024` −4.9%、`baseline-h2c-4096` −5.4%；`CPU/req` 11.53（−1.4%）/
   11.56（+1.5%）/ 10.94（+0.4%）/ 11.99（+5.1%）/ 12.75（+6.3%）；五档核数全在
   **6 072.9% ~ 6 417.7%**（吃满）。

   **同一轮里 h1 的 `baseline-4096` 是反方向的**（+1.4%，`CPU/req` 36.50，−7.1%，核数
   6 713.7% → 6 322.2%），而那一档与本族**共用同一条处理函数**（`/baseline*` 的查询求和）
   ⇒ **不是处理函数变贵了**，也不是本轮任何一笔改动的直接目标。**记形状，不编理由**：
   −2.0% / −2.2% / −2.3% 落在第五轮那组外部漂移（1.4% ~ 3.2%）的边缘，**−4.9% 与 −5.4%
   （都是 h2c）在漂移之外**。（顺带记一处口径：`baseline-4096` 第六轮是 6 713.7%，
   也就是 **> 6 400%** —— cpuset 只有 64 个逻辑核。`cpu.stat` 的窗口与 `rps` 的窗口不完全
   重合，超过 100% 的那部分按"吃满"读，不要当成"用了 67 个核"。）

6. **`echo-ws-pipeline-4096` −6.8% 是单档最大的回退，而它是计分档。**
   31 601 507 → 29 440 675，`CPU/req` 2.03 → 2.31（+13.8%），核数 6 798.7%。同族的另外两格
   （−0.2% / −0.3%）不动，`echo-ws-512/4096/16384` 是 −0.1% / −3.1% / −1.7%。
   本轮**没有碰 ws 那条路**，pin 那两笔也都不在它的调用图上。**记形状，不编理由。**

7. **其余各档持平。** h1 那几档：`baseline-4096` +1.4%、`limited-conn-4096` +2.1%、
   `async-32000` +0.6%、`latency-10k-1024` −0.0%、`latency-1m-1024` +0.0%、
   `latency-500k-8cpu-1024` −1.6%、`8gbit-512` −0.1%。
   `json-tls-4096` **−0.9%**（`CPU/req` 163.24，+6.1%）—— 它**没有**变便宜，
   标准序列化器那笔仍在（那三档 JSON 只有 `json-comp` 那一族吃到了 `16cba4a`，
   因为只有它协商的是 br）。
   `unary-grpc` 四档 −0.4% ~ −2.5%；`baseline-h3-64` +1.6%。
   `production-stack` 两档 −0.8% / +1.9%，核数 4 827.6% / 4 292.0% —— **没吃满**，
   所以它们的 rps 不由我们的每请求成本决定（第六轮已经确认它们的瓶颈在组成）。
   `gateway-h3-64` +4.2%（`CPU/req` 454.65，−20.4%）、`gateway-h3-256` −1.5%，
   两档也都**没吃满**（3 796.8% / 2 954.5%）。
   `async-db-1024` −1.0%（那一档是 Reference-only，不进合成分）。

8. **这一轮对合成分的净影响 —— 按"计分档"算，不按"涨了多少"算。**

   - **计分且涨**：`static-h2-256` +231.4%、`static-h2-1024` +128.5%、
     `static-h3-64` +110.8%、`json-comp-4096` +296.8%、`json-comp-16384` +234.2%、
     `gateway-64-512` +62.9%、`gateway-64-1024` +63.8%、`gateway-h3-64` +4.2%。
   - **计分且跌**：`baseline-h2-256/1024`（−2.2% / −2.0%）、
     `baseline-h2c-256/1024/4096`（−2.3% / −4.9% / −5.4%）、
     `echo-ws-pipeline-4096`（−6.8%）、`echo-ws-4096`（−3.1%）、
     `unary-grpc-tls-1024`（−2.5%）。
   - **不计分**：`static-tls-1024`（+186.0%，`scored: false`）、`pipelined-4096`（+2.4%）、
     `latency-500k-8cpu-1024`（−1.6%）、`async-db-1024`（−1.0%）。

   ⇒ 净是**大幅正**的，而且两侧的量级不成比例：涨的那五格在**几十到几百个百分点**上，
   跌的那几格在 **2 ~ 7%** 上。这一轮之后榜上该动的是 `h2` 的 `static-h2` 两格与 `h3` 的
   `static-h3-64`、`h1` 的 `json-comp` 两格，以及 `gw` 的 `gateway-64` 两格 —— 见下面
   「榜上的位置」。

这一轮的数字是这么取的（结果 JSON 在**分支上的 bot 提交**里，不在 PR 评论里）：

```sh
git show 69ff884:site/data/results/libuvcpp.json                # 本轮全表
git log --oneline 02ae418..1f6a8fb -- src/                      # 库：上面第 1 条
git log --oneline 9b0c2e2..d4c8625 -- frameworks/libuvcpp/      # 条目：上面第 2、3 条
```

#### 第八轮：1.7.2-dev 的读数（2026-10-17T10:40Z，42 档）

**这一轮只做了一件事，但它一次落在六个档上：条目的 `/json` 与 `/async-db` 两条应答从
`nlohmann` 的 DOM 换成库自己的 yyjson 后端 —— builder 建树、yyjson 自己的序列化器写出
（`uvcpp_json_builder` + `uvcpp_json_write`）。** 它是上一轮那个"合规撤回"的正式答案：
撤掉我们手写的流写器之后，被允许的替代就是一份生产级库，而 yyjson 是**本库自己 bundle
的那一份**（六条发布腿全传 `-DUVCPP_ENABLE_YYJSON=ON`），条目只是把那个开关打开，
`main.cc` 里连 `<yyjson.h>` 都不出现。

| | 第七轮 | **第八轮** |
|---|---|---|
| 平台的结果提交 | `69ff884`（2026-10-16T08:58:58Z） | `fcfd2d0`（2026-10-17T10:40:18Z） |
| 被测的那棵树 | `d4c8625` | `6f4f750` |
| 库 pin（`ARG LIBUVCPP_REF`） | `1f6a8fb`（`1.7.2-dev`） | `134f34d`（`1.7.2-dev`） |
| 档数 | 42 | 42 |

```sh
$ git log --oneline d4c8625..6f4f750 -- frameworks/libuvcpp/
6f4f750 Answer /json and /async-db through the framework's bundled yyjson backend

$ git log --oneline 0f34937..134f34d -- src/
134f34d Merge remote-tracking branch 'origin/master' into release/1.6.1
a063645 feat(json): yyjson 补上"完整写入"—— 构造侧 builder + 用 yyjson 自己的写器写回（1.7.2-dev）
c61b992 fix(db): ODBC 后端在 mingw 上编不过 —— unixODBC 补的 WCHAR 与 winnt.h 硬冲突（1.7.2-dev）
ac10a6d Merge remote-tracking branch 'origin/master' into feature/db-odbc
638512b perf(web): h1 动态热路上的三处白拷（1.7.2-dev）
...（ODBC 那一族余下六笔见 `git log`）
```

（pin 从 `0f34937` 往前走了 **19** 笔，`-- src/` 里只有三类：`a063645` 是这一轮的动因、
`638512b` 是库侧 h1 热路、其余是第四个数据库后端 ODBC —— 条目把它显式关掉了
（`-DUVCPP_ENABLE_DB_ODBC=OFF`），所以那一整族在这一轮是惰性的。）

全表（42 档，按 `rps` 降序；`CPU/req` 是 `CPU% ÷ rps`，有 `cpu_per_req_us` 的四档用平台那个值）：

| 档 | rps | 七→八 | CPU/req | 七→八 | RSS |
|---|---:|---:|---:|---:|---:|
| `echo-ws-pipeline-512` | 33 213 203 | +8.3% | 2.05 µs | −5.3% | 78 MiB |
| `echo-ws-pipeline-4096` | 32 736 147 | +11.2% | 1.94 µs | −16.2% | 135 MiB |
| `echo-ws-pipeline-16384` | 29 129 603 | +3.6% | 2.13 µs | −3.5% | 348 MiB |
| `pipelined-4096` | 7 848 400 | +4.6% | 8.25 µs | −2.3% | 150 MiB |
| `baseline-h2c-256` | 5 889 601 | +6.1% | 10.52 µs | −3.8% | 81 MiB |
| `baseline-h2c-1024` | 5 709 089 | +8.1% | 11.25 µs | −6.1% | 164 MiB |
| `baseline-h2-256` | 5 501 093 | +3.7% | 11.49 µs | −0.3% | 110 MiB |
| `baseline-h2c-4096` | 5 489 431 | +9.1% | 11.64 µs | −8.7% | 766 MiB |
| `baseline-h2-1024` | 5 430 750 | +1.9% | 11.57 µs | +0.1% | 172 MiB |
| `unary-grpc-256` | 3 837 633 | +1.0% | 16.23 µs | −0.9% | 173 MiB |
| `unary-grpc-tls-256` | 3 664 147 | −0.5% | 16.83 µs | +0.2% | 165 MiB |
| `unary-grpc-1024` | 3 600 218 | −1.8% | 17.65 µs | +2.0% | 428 MiB |
| `unary-grpc-tls-1024` | 3 517 793 | +2.1% | 17.46 µs | −6.6% | 591 MiB |
| `baseline-h3-64` | 3 239 525 | +5.3% | 11.58 µs | −2.5% | 103 MiB |
| `echo-ws-4096` | 3 007 035 | +5.9% | 21.00 µs | −7.1% | 131 MiB |
| `echo-ws-512` | 2 892 280 | +1.5% | 22.52 µs | −4.7% | 79 MiB |
| `echo-ws-16384` | 2 673 301 | +4.2% | 23.04 µs | −10.5% | 329 MiB |
| `echo-ws-limited-4096` | 1 832 895 | +3.1% | 33.85 µs | −4.3% | 93 MiB |
| `baseline-4096` | 1 802 593 | +4.1% | 34.87 µs | −4.5% | 139 MiB |
| `echo-ws-limited-512` | 1 633 110 | +3.7% | 35.82 µs | −6.4% | 85 MiB |
| `async-32000` | 1 529 805 | −0.8% | 40.04 µs | +0.6% | 489 MiB |
| `limited-conn-4096` | 1 480 567 | +4.7% | 42.53 µs | −4.4% | 86 MiB |
| `json-h2c-1024` | 1 187 769 | +81.3% | 53.52 µs | −45.4% | 332 MiB |
| `json-h2c-4096` | 1 130 987 | +76.7% | 54.70 µs | −45.6% | 1.3 GiB |
| `latency-1m-1024` | 997 805 | −0.0% | 38.30 µs | −4.3% | 82 MiB |
| `static-h2-256` | 806 684 | +0.5% | 80.07 µs | −0.2% | 240 MiB |
| `json-tls-4096` | 619 671 | +55.0% | 102.66 µs | −37.1% | 406 MiB |
| `static-tls-1024` | 571 215 | +0.4% | 114.74 µs | +0.9% | 273 MiB |
| `static-h2-1024` | 550 039 | +0.5% | 113.46 µs | −3.3% | 507 MiB |
| `json-comp-16384` | 291 220 | +47.4% | 223.31 µs | −27.7% | 152 MiB |
| `json-comp-4096` | 285 759 | +42.9% | 218.16 µs | −30.5% | 111 MiB |
| `latency-500k-8cpu-1024` | 271 901 | +4.5% | 29.33 µs | −4.3% | 32 MiB |
| `production-stack-256` | 256 279 | −0.1% | 185.95 µs | −1.2% | 1.2 GiB |
| `gateway-64-512` | 240 386 | +20.6% | 234.42 µs | −14.0% | 1.5 GiB |
| `static-h3-64` | 238 175 | −0.4% | 176.63 µs | +0.7% | 475 MiB |
| `gateway-64-1024` | 233 849 | +18.9% | 256.52 µs | −3.8% | 2.0 GiB |
| `production-stack-1024` | 208 500 | +0.1% | 205.51 µs | −0.3% | 2.0 GiB |
| `async-db-1024` | 95 435 | +10.4% | 293.00 µs | −25.2% | 185 MiB |
| `gateway-h3-64` | 84 759 | +1.5% | 422.15 µs | −7.1% | 415 MiB |
| `gateway-h3-256` | 62 533 | +1.3% | 446.55 µs | −6.7% | 1.4 GiB |
| `8gbit-512` | 49 340 | +0.1% | 67.18 µs | +2.5% | 209 MiB |
| `latency-10k-1024` | 9 981 | +0.0% | 38.27 µs | +2.5% | 79 MiB |

**正确性**：42 档全部有数，`5xx` **0**、`4xx` **0**。

1. **五档 JSON：+42.9% ~ +81.3%，`CPU/req` −27.7% ~ −45.6%，而且与条目侧 A/B 逐点重合。**

   | 档 | 七 rps | 八 rps | rps | CPU/req 七 → 八 |
   |---|---:|---:|---:|---:|
   | `json-h2c-1024` | 655 129 | **1 187 769** | +81.3% | 98.04 → 53.52 µs（−45.4%） |
   | `json-h2c-4096` | 639 897 | **1 130 987** | +76.7% | 100.53 → 54.70 µs（−45.6%） |
   | `json-tls-4096` | 399 878 | **619 671** | +55.0% | 163.24 → 102.66 µs（−37.1%） |
   | `json-comp-16384` | 197 549 | **291 220** | +47.4% | 308.74 → 223.31 µs（−27.7%） |
   | `json-comp-4096` | 199 935 | **285 759** | +42.9% | 313.79 → 218.16 µs（−30.5%） |

   `json-h2c` 那两档是本报告里 JSON 第一次过百万 rps。**归因不是猜的**：条目侧在另一套装置上
   （同一份库、只换 `main.cc`、四轮交替、平台自己的 pipeline=1 形状）量的是 `/json/50?m=6`
   **228.60 → 125.31 µs**（−45.18%），平台 `json-h2c-1024` 是 98.04 → 53.52 µs（−45.4%）——
   两条独立的路差 0.2 个百分点。

   三档之间那个梯度也是可预期的：`json-comp` 只到 −27.7% / −30.5%，因为那一档的 gzip 本身
   占着大头，JSON 在总成本里的份额被摊薄；`json-tls` −37.1% 介于两者之间（TLS 出口摊掉
   一部分）。**"被序列化占掉的比例"决定涨幅 —— 这个梯度就是它的指纹。**

2. **`async-db-1024` +10.4%，`CPU/req` 391.97 → 293.00 µs（−25.2%）**，条目侧同一笔改动。
   条目侧 A/B 是 258.62 → 158.95 µs（−38.5%），平台只兑现 10.4% 的 rps —— 因为这档在平台上
   **是 Postgres 延迟受限，不是 CPU 受限**（§4.21 与 `adb` 那套装置的结论）。省下的服务端
   CPU 换不来同比例的吞吐，**方向与量级都对得上**。这一档 Reference-only，不进合成分。

3. **`gateway-64` 两档 +20.6% / +18.9%，不是新现象：它的 URI 混合里一半正好走上面两条路。**
   `requests/gateway-64-uris.txt` 是 **6 条 `/static/*` + 4 条 `/baseline2` + 7 条 `/json/*`
   + 3 条 `/async-db`**：20 条里 10 条吃这一轮，一半流量快 2~3 倍 ⇒ 混合均值约 +20%。
   `CPU/req` 272.46 → 234.42（−14.0%）与 266.70 → 256.52（−3.8%）也自洽 —— 512 那格是
   每请求变便宜，1024 那格是**多用核**把管道推满（5 245.2% → 5 998.6%）。

4. **其余各档全在漂移带里，而这一轮的负对照正好在场上。** 四档静态（`static-h2-256` +0.5%、
   `static-h2-1024` +0.5%、`static-tls-1024` +0.4%、`static-h3-64` −0.4%）这一轮**既没被改、
   也没有任何改动落在它们的调用图上**，它们给出的是机器状态；而全场 42 档的**中位是 +3.7%**。
   ⇒ 那 3~9% 的普涨是机器，不是代码。`echo-ws-pipeline-4096` +11.2% 是带子上沿的单格，
   同族另外两格 +8.3% / +3.6%；`baseline-h2c` 那三格 +6.1% / +8.1% / +9.1% 也在带子上沿。
   **记形状，不编理由** —— 这一轮没有任何改动落在 h1/h2 的响应路径上（唯一的库侧 h1 改动
   见第 5 条，`-- src/` 里其余都是 ODBC），带子上沿与正中间之间的差就是这个装置的噪声。

5. **`638512b`（库侧 h1 动态热路的三处白拷）这一轮在 pin 里，但不认领它。**
   `baseline-4096` +4.1%（`CPU/req` 36.50 → 34.87，−4.5%）、`limited-conn-4096` +4.7%、
   `pipelined-4096` +4.6% —— 全在漂移带里，与静态对照给出的量级分不开。**它是库侧的，
   验收该在库自己的装置上做**；提交信息里也只声称 −3~−4% 端到端并明说不作板面预测。

6. **`latency-500k-8cpu-1024` 仍挂在 ⚠️ 上，这一轮没有针对它做任何事。**
   260 201 → 271 901（+4.5%）、`cpu_per_req_us` 30.65 → 29.33（−4.3%）、rate
   0.5204 → **0.5438**。这点动属于漂移；**它是下一轮的目标。**

7. **内存混着两个方向，不记成回归也不记成改善。** `json-h2c-4096` 1 016 → 1 331 MiB（+31%）、
   `json-comp-16384` 120 → 152 MiB（+27%）、`static-h3-64` 302 → 475 MiB（+57%），而
   `json-tls-4096` 662 → 406 MiB（−39%）、`static-h2-1024` 659 → 507 MiB（−23%）。builder
   的 pool 随"同时在写的应答数"增长，方向取决于并发形状；静态腿那两格方向相反，且它没有任何
   代码改动 ⇒ **这个计数的方差本身就比这些差大**（RSS 量的是进程峰值，不是稳态）。先记形状。

8. **与榜面的关系（免得误读 bot 评论里的 `Δ RPS`）。** 那张表的 Δ 是对 **`main` 上现存的
   第四轮**算的（`json-comp-4096` −12.2% = 325 476 × 0.878），**不是**对本节里的第七轮。
   所以合并后 json 那几行**相对榜面**是下降的（`json-comp` −12.2% / −9.3%、`json-h2c`
   −20.6% / −23.9%、`json-tls` −7.8%）—— 那是"换掉手写写器"的既定代价，不是这一轮的倒退。
   **这一轮的对照是第七轮，五档 JSON 全部大幅转正。**

这一轮的数字是这么取的：

```sh
git show fcfd2d0:site/data/results/libuvcpp.json                # 本轮全表
git show 69ff884:site/data/results/libuvcpp.json                # 第七轮全表
git log --oneline 0f34937..134f34d -- src/                      # 库：上面第 1、5 条
git log --oneline d4c8625..6f4f750 -- frameworks/libuvcpp/      # 条目：第 1、2、3 条
```

#### 对照基线：第二轮（2026-10-12，26 档）

下表是**第二轮**（2026-10-12）的 26 档，条目钉在 `3fdd6208` —— `v1.6.1` 当时指向的那个
提交。窗口 5 s，`latency-*` 那三档 20 s：

| 档 | rps | `2xx` | `5xx` | CPU | RSS |
|---|---:|---:|---:|---:|---:|
| `8gbit-512` | 49 312 | 246 623 | 0 | 357.4% | 147 MiB |
| `async-32000` | 725 202 | 7 252 021 | 0 | 5 367.4% | 478 MiB |
| `async-db-1024` | 83 189 | 831 890 | 0 | 3 450.1% | 173 MiB |
| `baseline-4096` | 1 141 979 | 5 709 896 | 0 | 6 099.8% | 113 MiB |
| `baseline-h2-256` | 3 416 262 | 17 183 800 | 0 | 5 674.6% | 108 MiB |
| `baseline-h2-1024` | 3 327 227 | 16 802 500 | 0 | 5 662.9% | 267 MiB |
| `baseline-h3-64` | **58** | 294 | 0 | **4.2%** | 52 MiB |
| `echo-ws-512` | 2 793 537 | 13 967 689 | 0 | 6 755.5% | 57 MiB |
| `echo-ws-4096` | 2 887 784 | 14 438 924 | 0 | 6 681.6% | 113 MiB |
| `echo-ws-16384` | 2 626 001 | 13 130 007 | 0 | 6 657.4% | 316 MiB |
| `echo-ws-limited-512` | 1 512 438 | 7 562 192 | 0 | 5 813.7% | 69 MiB |
| `echo-ws-limited-4096` | 1 722 414 | 8 612 072 | 0 | 6 144.3% | 71 MiB |
| `echo-ws-pipeline-512` | 10 846 084 | 54 230 420 | 0 | 6 392.0% | 58 MiB |
| `echo-ws-pipeline-4096` | 12 632 957 | 63 164 789 | 0 | 5 901.9% | 115 MiB |
| `echo-ws-pipeline-16384` | 10 629 843 | 53 149 217 | 0 | 6 330.8% | 326 MiB |
| `json-comp-4096` | 194 410 | 972 051 | 0 | 6 321.2% | 90 MiB |
| `json-comp-16384` | 192 334 | 961 671 | 0 | 6 476.5% | 170 MiB |
| `json-tls-4096` | 370 872 | 1 890 095 | 0 | 6 452.9% | 646 MiB |
| `latency-10k-1024` | 9 983 | 199 678 | 0 | **40.5%** | 59 MiB |
| `latency-1m-1024` | 953 409 | 19 072 591 | 0 | 5 448.5% | 63 MiB |
| `latency-500k-8cpu-1024` | 254 662 | 5 095 324 | 0 | **776.6%** | 29 MiB |
| `limited-conn-4096` | 907 798 | 4 538 993 | 0 | 5 545.2% | 65 MiB |
| `pipelined-4096` | 3 612 234 | 18 061 172 | 0 | 5 953.6% | 135 MiB |
| `static-h2-256` | 149 781 | 753 403 | 0 | 3 334.8% | 1.3 GiB |
| `static-h2-1024` | 157 097 | 793 344 | 0 | 3 425.2% | **3.7 GiB** |
| `static-tls-1024` | 115 239 | 587 700 | 0 | 2 901.0% | 302 MiB |

（`async-32000` 与 `async-db-1024` 两档的 `2xx` 是 `rps × 10 s` 而不是 × 5 s，即计数窗口
与 `duration` 字段写的 `5s` 不一致；照抄平台字段，不折算。）

第二轮当时读出来的四条结论（第 2、3 条**已经被 1.7.0 那一轮翻掉**，见上）：

1. **`5xx` 一栏 26 个 `0`。** 这不是运气：两轮之间唯一会成片回 5xx 的那个缺陷（h2 的流被
   套上 h1 的在途上限）在第二轮那版库里已经不在，见下面「第一轮为什么不能当对照」——
   同一档在第一轮是 `556 357` / `561 555` 个 `5xx`。（第四轮是 **42 档 42 个 `0`**。）
2. **`baseline-h3-64` 是唯一一片洼地，而它的形状比数字说明得多**（**这一格在 1.7.0 那轮
   已经是一百万级，见上**）：58 rps、294 个 `2xx`、
   **CPU 4.2%**，也就是 0.04 个线程。服务端在**等**，不在算。294 ÷ 64 = 每连接 4.6 个响应，
   5 s ÷ 4.6 ≈ 1.09 s —— 几乎正好是 RFC 9002 的初始 PTO。这一格是
   [`benchmark-rig.md`](benchmark-rig.md) 里那套本地 h3 量具**保真**的证据：两边量到的
   绝对值不同，病理的形状一致。（第二轮钉的 `3fdd6208` **不含**短包头 DCID 解码那一处
   修复，即 `CHANGELOG.md` 里 `745608c` 那条，所以这一格是**修复前**的读数。）
3. **`static-h2` 的内存是独立的一条线**：1024 档 3.7 GiB、256 档 1.3 GiB，而 CPU 只有
   3 425% / 3 335% —— 它**不是**算力受限的那一档，别拿它跟第 4 条并列。
   （**1.7.0 那轮这两格已经是 793 MiB / 189 MiB**，而它的吞吐反倒涨到了 242 380 / 238 807。）
4. **`cpu_per_req_us` 只有不饱和的档读得出来**：`8gbit` 72.10、`latency-1m` 53.40、
   `latency-10k` 42.30、`latency-500k-8cpu` 31.33 µs。其余吞吐档的 CPU 都落在 5 500–6 700%，
   也就是**服务端把自己那半个芯片吃满了** —— 那些 rps 是它的上限，不是还有余量。
   （`latency-500k-8cpu` 那一档按名字就把服务端钉死在 8 个 CPU 上，它的 776.6% 要跟 8 比、
   不是跟 64 比。1.7.0 那轮这四个数是 70.81 / **41.84** / 40.52 / 32.56 µs —— `latency-1m`
   掉了 20%，而它的 rps 只 +4.7%：这一档是**变便宜了但没有变快**。）

#### 六轮之间怎么比：第一轮为什么不能当对照

条目在榜上跑过**七轮**：**第一轮** 2026-10-10（20 档）、**第二轮** 2026-10-12（26 档，钉
`v1.6.1`）、**第三轮** 2026-10-13 —— **那天跑了两次**（42 档，分别钉 `1.6.20-dev` 与
`1.6.22-dev`）、**第四轮** 2026-10-14（42 档，钉 `1.6.51-dev`，就是 1.7.0 那一轮）、
**第五轮** 2026-10-15（42 档，钉 `1.7.2-dev`；见上）、**第六轮** 2026-10-15T17:03Z（42 档，
钉 `1.7.2-dev`；见上）、**第七轮** 2026-10-16T08:58Z（42 档，钉 `1.7.2-dev`；见上）。
七轮的对照价值不一样：**第一轮不能
当对照**，**第三轮那两次之间是能用的最细一格**（那个区间里只有两条库提交加两条条目提交），
而本报告里几乎每条归因都建在"第二 → 第三/第四/第五/第六/第七"或"第三轮那两次之间"上。
**第五轮的对照组比前几轮宽**：连被外部因子钉住的那几档都集体上浮了 1.4%~3.2%，
所以它那一轮 ±3% 以内的涨幅不算数（见上）。**第六轮不是库的对照** —— 它同时换了序列化器、
换了压缩编码器、换了边的实现，见上一小节的第 1、2、6 条。**第七轮也不是纯库的对照** ——
它同时动了库侧一笔（静态腿那把锁）、条目侧两笔（h3 静态腿的校验线程、把 brotli 编回去），
三件事各打各的档，详见它那一小节的第 1、2、3 条。

第一轮与第二轮之间的差**不能归因给任何一件事**，因为同时变了三样：库从 `1.6.0` 的**发布包**
换成从源码构建的 `3fdd6208`；条目的控制台日志阈值从 `WARN` 换成 `OFF`；订阅的档从
15 个变成 18 个（第二轮多了 `async-db` 与三个 ws 档）。同名的 20 档里，
`latency-10k-1024` 一格没动（+0.0%）、`8gbit-512` 只 +0.3%，而 `echo-ws-*` 全在
+93% ~ +98%、`static-h2` 是 +233% / +293% —— 这个分布本身就说明它不是单一原因。

唯一的例外是 `static-h2`，那里有一条**闭合**的归因：

| `static-h2` | `2xx` | `5xx` | 两者之和 | 得到 2xx 的比例 |
|---|---:|---:|---:|---:|
| 第一轮，1024 连接 | 238 313 | 556 357 | **794 670** | 30.0% |
| 第二轮，1024 连接 | 793 344 | 0 | **793 344** | **100%** |
| 第一轮，256 连接 | 191 703 | 561 555 | **753 258** | 25.4% |
| 第二轮，256 连接 | 753 403 | 0 | **753 403** | **100%** |

两轮**收到的请求数只差 0.2%**（794 670 → 793 344、753 258 → 753 403），而 `rps` 那一栏涨了
233% / 293% —— 因为 `rps` 只把 `2xx` 算进去。拿第一轮对一下就知道：`238 313 ÷ 5 s` = 47 663，
与它记的 `47 190` 差 1%（生成器侧的成功计数与窗口边界差那么一点）；若把 `5xx` 也算进去
该是 158 934。**所以那一档的负载一点没变，变的只是这些请求里有多少拿到了 2xx。**
原因是 `1.6.1` 那条修复：h1 的每连接在途上限（默认 8）此前也套在 h2 流上，超出的流被回
`503` 加 `connection: close` —— 而在 h2 上 `connection` 是非法头（RFC 9113 §8.2.2），
一条流不该决定连接级的事。

**五轮的分档表**（同名 26 档，`rps`；右边四列是相邻两轮的比值变化，用来看"哪一段涨的"）：

| 档 | 二 `v1.6.1` | 三a `1.6.20` | 三b `1.6.22` | 四 `1.6.51` | 五 `1.7.2` | 二→三a | 三a→三b | 三b→四 | 四→五 |
|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|
| `echo-ws-pipeline-512` | 10 846 084 | 4 300 255 | 31 022 444 | 30 027 149 | 31 580 057 | −60.4% | +621.4% | −3.2% | +5.2% |
| `echo-ws-pipeline-4096` | 12 632 957 | 3 940 115 | 30 212 348 | 28 938 721 | 31 035 676 | −68.8% | +666.8% | −4.2% | +7.2% |
| `echo-ws-pipeline-16384` | 10 629 843 | 3 806 678 | 27 039 040 | 25 179 465 | 27 866 425 | −64.2% | +610.3% | −6.9% | +10.7% |
| `pipelined-4096` | 3 612 234 | 3 355 109 | 3 460 583 | 6 784 375 | 7 491 589 | −7.1% | +3.1% | +96.0% | +10.4% |
| `baseline-h2-1024` | 3 327 227 | 3 246 976 | 3 354 792 | 4 688 932 | 5 247 351 | −2.4% | +3.3% | +39.8% | +11.9% |
| `baseline-h2-256` | 3 416 262 | 3 430 755 | 3 346 819 | 4 498 827 | 5 552 266 | +0.4% | −2.4% | +34.4% | +23.4% |
| `echo-ws-4096` | 2 887 784 | 2 883 179 | 2 885 850 | 2 844 300 | 2 884 971 | −0.2% | +0.1% | −1.4% | +1.4% |
| `echo-ws-512` | 2 793 537 | 2 826 305 | 2 803 369 | 2 751 709 | 2 833 406 | +1.2% | −0.8% | −1.8% | +3.0% |
| `echo-ws-16384` | 2 626 001 | 2 554 905 | 2 602 402 | 2 516 942 | 2 577 600 | −2.7% | +1.9% | −3.3% | +2.4% |
| `echo-ws-limited-4096` | 1 722 414 | 1 647 690 | 1 644 781 | 1 777 709 | 1 767 053 | −4.3% | −0.2% | +8.1% | −0.6% |
| `baseline-4096` | 1 141 979 | 1 155 937 | 1 183 307 | 1 639 189 | 1 789 003 | +1.2% | +2.4% | +38.5% | +9.1% |
| `echo-ws-limited-512` | 1 512 438 | 1 469 114 | 1 478 910 | 1 550 796 | 1 600 650 | −2.9% | +0.7% | +4.9% | +3.2% |
| `async-32000` | 725 202 | 755 849 | 758 016 | 1 513 512 | 1 568 496 | +4.2% | +0.3% | +99.7% | +3.6% |
| `limited-conn-4096` | 907 798 | 860 638 | 854 825 | 1 309 891 | 1 414 762 | −5.2% | −0.7% | +53.2% | +8.0% |
| `baseline-h3-64` | 58 | 1 178 068 | 1 133 149 | 1 167 034 | 1 422 023 | **+2 031 051.7%** | −3.8% | +3.0% | +21.8% |
| `latency-1m-1024` | 953 409 | 957 078 | 950 355 | 997 940 | 998 040 | +0.4% | −0.7% | +5.0% | +0.0% |
| `json-tls-4096` | 370 872 | 372 754 | 568 719 | 672 436 | 724 360 | +0.5% | **+52.6%** | +18.2% | +7.7% |
| `json-comp-4096` | 194 410 | 191 970 | 292 307 | 325 476 | 335 926 | −1.3% | **+52.3%** | +11.3% | +3.2% |
| `json-comp-16384` | 192 334 | 192 091 | 289 783 | 321 152 | 330 411 | −0.1% | **+50.9%** | +10.8% | +2.9% |
| `latency-500k-8cpu-1024` | 254 662 | 245 748 | 243 248 | 245 021 | 264 277 | −3.5% | −1.0% | +0.7% | +7.9% |
| `static-h2-1024` | 157 097 | 162 495 | 159 233 | 242 380 | 252 927 | +3.4% | −2.0% | **+52.2%** | +4.4% |
| `static-h2-256` | 149 781 | 159 672 | 161 184 | 238 807 | 232 078 | +6.6% | +0.9% | **+48.2%** | −2.8% |
| `static-tls-1024` | 115 239 | 135 636 | 133 969 | 190 096 | 190 070 | +17.7% | −1.2% | **+41.9%** | −0.0% |
| `async-db-1024` | 83 189 | 82 708 | 82 891 | 83 890 | 98 855 | −0.6% | +0.2% | +1.2% | +17.8% |
| `8gbit-512` | 49 312 | 49 317 | 49 197 | 49 175 | 49 344 | +0.0% | −0.2% | −0.0% | +0.3% |
| `latency-10k-1024` | 9 983 | 9 981 | 9 982 | 9 983 | 9 981 | −0.0% | +0.0% | +0.0% | −0.0% |

读法三条：

1. **这套装置的重复性下限大约是 ±2%。** 第三轮那两次之间只差两条库提交，而其中一条
   （`219b0da`）只该影响 ws 流水线，另一条（`c8950ae`）只该影响 JSON —— 于是其它档的差就是
   噪声：`8gbit-512` −0.2%、`latency-10k-1024` +0.0%、`latency-500k-8cpu-1024` −1.0%、
   `echo-ws-512/4096/16384` −0.8% / +0.1% / +1.9%、`async-db-1024` +0.2%、
   `latency-1m-1024` −0.7%。**跨过 ±10% 的格子才读得出东西**，表里加粗的都是。
2. **九档在二~四轮里全程不动**：`8gbit-512`、`latency-10k-1024`、`latency-500k-8cpu-1024`、
   `latency-1m-1024`、`echo-ws-512/4096/16384`、`echo-ws-limited-512`、`async-db-1024`。
   它们各自被外部因子钉住（带宽 / 往返时延 / 只给 8 个 CPU / 回显 / Postgres），所以正好是
   **对照**：任何"机器变快了"或"生成器换了"的解释，都得先解释这九档为什么没跟着动。
   —— **第五轮是这条的一个例外，而且是个有用的例外**：那一轮里除了 `async-db-1024`
   （+17.8%，原因已知，见上）之外，另外八档自己上浮了 +0.0% ~ +3.2%，其中
   `latency-500k-8cpu-1024` 到了 +7.9%（那一档是被它那 8 个 CPU 钉住的，所以它动的时候
   动的是"每请求 CPU"，那一轮 `CPU/req` 是 −6.8%）。**对照自己会动的那一轮，"小涨"就不能
   当信号读。**
3. **同一个库版本上，同一档的口径是稳的**：`baseline-h3-64` 是 1 178 068 → 1 133 149 →
   1 167 034 → 1 422 023，前三轮 ±2%（第五轮那一跳 +21.8% 是上面第 4 条那组里的一个），
   这说明第三轮就已经修好、而且修的是**一个恒定形状**，不是偶尔撞上。
   `echo-ws-pipeline-*` 在第三轮两次之间 ×7.2 —— 这一格的变化幅度本身就排除了噪声解释。

#### 榜上的位置（2026-10-15 读）

家族分是**同家族各档分数之和**，所以「没订阅的档」等于「整档 0 分」：

| 家族 | 我们的分 | 家族内 | 榜首 |
|---|---:|---|---:|
| h1 | 5 037.3 | #11/76 | tako **6 993.3** |
| h2 | **2 119.5** | **#3/23** | bun **3 402.4** |
| h3 | **734.1** | **#5/13** | bun **1 950.0** |
| ws | 2 022.8 | #4/23 | genhttp-ioxide **2 632.7** |
| gw | **1 454.1** | **#4/7** | fulmine.js **2 536.3** |
| grpc | **1 746.4** | **#2/6** | wtx **2 000.0** |

（`https://www.http-arena.com/badge/index.json`；取的是**默认档** —— `tuned=0` 且
`type ∈ {flagship, emerging}`。同一份数据里还并列着一份 `withTuned`，两边的名次不同，
引用时要说清是哪一份：我们那条 `withTuned` 是 h1 #15/97、h2 #4/31、h3 #7/16、ws #4/31、
gw #4/8、grpc #2/10；h1 另有一条按语言比的 `byLanguage`，我们 **#1/4**。）

**这一读比 10-14 那一读整个换了，换的是主仓那份结果文件。** 上一读是 h1 3 382.3 / #25、
h2 603.9 / #15、h3 0.0 / #13、ws 1 639.2 / #10、gw 与 grpc 未订阅；现在 `main` 上的
`site/data/results/libuvcpp.json` **与第四轮的结果提交逐字节相同**
（`git log origin/main -- site/data/results/libuvcpp.json` 只有 `af3b4fc` 与 `53f4911`，
都是 #1553 那次合并）⇒ 榜上这组分数读的是**第四轮**（pin `6eede33` = 1.7.0），
不再有"榜上还是第二轮"那回事。逐族都能对回上面那张五轮分档表（下面的百分比都是**二 → 四**
总计，跨那三步）：h1 那 3 382.3 → 5 037.3 落在 `baseline-4096` 的 +43.5%、
`limited-conn-4096` 的 +44.3%、`async-32000` 的 +108.7%、`json-comp-4096` / `-16384` 的
+67.4% / +66.9%、`json-tls-4096` 的 +81.3% 上；h2 那 603.9 → 2 119.5 落在 `static-h2-*`
与 `baseline-h2-*` 的 +31.7% ~ +59.4% 上；h3 那 **0.0 → 734.1** 是两件事叠起来的 —— `baseline-h3-64` 从 58 rps
到 1 167 034（CID 那条修好之后）**加上这一族新进来的 `static-h3-64`**（114 206 rps，
零 5xx）；gw 与 grpc 两整族也是这一次才进来的（两族第三轮就订上了，但它们的档要等结果
文件更新才在榜上出现）。

**第五、第六、第七三轮都还在 PR #1568 那条分支上** —— 那条分支 tip 上的结果提交现在是
**第七轮**的 `69ff884`（`16e6e49` 与 `6fadb86` 都是它的祖先），要等合进主仓才会跟着更新。
**所以合并进去时上榜的是第七轮那一份**，不是上表这一读（上表仍是第四轮）。三棵树对家族分的
影响要按**累计**读，不能只读最后那一轮：

- **一路累计在掉的**：`h1` 的 `json-comp-4096` / `json-comp-16384`（第五轮 vs 第四轮
  +67.4% / +66.9%，第七轮 vs 第五轮 −40.5% / −40.2%）与 `json-tls-4096`（第七轮 vs
  第四轮仍有标准序列化器那笔）；`h2` 的 `json-h2c-1024` / `-4096`（六轮 −60.3% / −59.9%，
  第七轮没变）。**这三族的下滑是合规的代价**（MDA2AV 要求用 `nlohmann` 这样的正经
  JSON 解析器），不是可以回头去要回来的分。
- **一路累计在涨的**：`h2` 的 `static-h2-256` / `static-h2-1024`（七轮 +231.4% / +128.5%，
  而且它们这一轮**才第一次**顶到 64 核）；`h3` 的 `static-h3-64`（七轮 +110.8%）与
  `baseline-h3-64`（六轮 +113.1%）；`h1` 的 `json-comp` 两档虽然仍低于第四轮，
  但已经收回六轮丢掉的那 85% / 82% 的大部分；`gw` 整族（六轮 +58.5% / +74.4% /
  +378.2% / +321.9%，七轮再 +62.9% / +63.8%）。
- **不进合成分的**：`async-db-1024`（Reference-only）、`static-tls-1024`（`scored: false`）、
  `pipelined-4096` 与 `latency-500k-8cpu-1024`（`scored: false`）。

⇒ 与第六轮那一读（对 h1 净亏）不同，**第七轮这一份对六个家族是净大幅正的**：涨的都在
几十到几百个百分点上，跌的那几格（`baseline-h2c-*` 最深的 −5.4%、`echo-ws-pipeline-4096`
的 −6.8%）都在个位数上。**但上表仍然读的是第四轮**，实际的家族分要等这一次合并之后才能
去 `badge/index.json` 读。

同族别人的分也在动，所以名次不是我们一个人的事：10-13 读到 h1 3 372.6 / #24、10-14 读到
3 382.3 / #25，而我们的原始读数那一格没动 —— 家族分是同族各档归一化之后的和，同族有人涨，
我们就掉。**引用这一节时把日期一起带上**：它是一张快照，不是常数。

### 4.6 JSON 写出器（**第五套装置**，仓外探针）

> 第五套装置：这一节也不在 4.1 / 4.2 的条目上，不是 4.3 的指令数，也不是 4.4 那支静态腿
> 探针。它是一根**只跑序列化**的仓外探针，语料是 HttpArena 的 `data/dataset.json`，形状
> 照着平台 `json-50` 那一档（50 项、整份响应 8 397 B），**不起事件循环、不发包**。所以它
> 量的是**每请求服务端用户态里「把 JSON 变成字节」这一段**，绝对值与任何一节都不可比；
> 有意义的是同一台机器、同一次会话里四个臂之间的差。装置、语料路径与绑核记在
> [`benchmark-rig.md`](benchmark-rig.md) 的「JSON 写出器的量具」一节。

**要回答的问题**：`json-*` 三档要求「每请求用**框架自己的**文档化序列化接口，从活数据
现算现序列化」（预序列化缓存在两种 type 上都不合规）。条目今天走的是
`nlohmann::json::dump()` 一项一项拼 —— 那么这 33 µs 里，**哪些是「序列化」本身、哪些只是
「拼接」**，换成框架自己的流式写出器之后又能吃掉多少？

下表一律写**区间**：每个臂绑核连量 5 轮（`taskset -c 2-3`），同一会话内 5 轮的离散度在
±0.5% 以内，但**两次会话之间还有约 4% 的漂移**（本机是桌面机），所以单点读数不能当真。

| 臂 | 形状 | 50 项响应（5 轮） | 与 A 之比 |
|---|---|---:|---:|
| A 今天的条目 | 每项 `dump()` 后 `append` 进同一个缓冲 | 32.77 ~ 32.91 µs | 1.00× |
| **W 框架写出器** | **`uvcpp_json_writer` 一趟直写，零临时串** | 29.31 ~ 29.90 → **20.66 ~ 20.90** | **1.57 ~ 1.59×** |
| F 手写一趟 | 栈上两位一取的整数表、光标直推预分配缓冲 | 15.50 ~ 16.29 µs | 2.01 ~ 2.12× |
| E 预算串（诊断） | 同一批字节，来自预先算好的每项字符串 | 3.19 ~ 3.42 µs | 9.6 ~ 10.3× |

（「A → W」那一格另有一支臂，把条目今天那份 `build_json` 与新写法**逐字照抄**成两臂同
进程交替量，得到 31.74 ~ 32.01 → 21.29 ~ 21.49 µs，即 **1.49 ~ 1.50×**；与上表 1.57 ~
1.59× 的差就是「同一会话里两支量具本身的 3% 差」，别把任一个当成精确值。）

四条读得出来的结论：

1. **那一项一项的开销里，一大半是「每次调用要跨出去几次 `std::string::append`」，不是
   转义、也不是整数转换。** 框架的 `key()` 原先把逗号、开引号、键体、闭引号、冒号**各
   追加一次**（一项里第一个键 4 次、其余 5 次），字符串值 3 次 —— 于是 8 397 B 的响应共
   **4 073 次** `append_raw`，平均**每 2.1 个字节一次**；每一次都得跨出翻译单元
   （`libstdc++` 的 `_M_append` 带容量检查与 `catch` 子句，内联不进来）。把整段拼在
   256 字节的**栈**缓冲上、再追加一次，同一个响应降到 **1 536 次**，W 因此 29.31 ~ 29.90
   → **20.66 ~ 20.90 µs**（写出器本身 1.42 ~ 1.44×）。
2. **E 的 3.3 µs 是「完全不序列化」的下界**，所以这份响应里 **约 90% 的开销确实是序列化**，
   拷字节与开缓冲加起来只占一成。E **只是诊断**：预序列化缓存正是这条档位规则对
   **两种 type 都**明令禁止的东西，它不是可选方案。
3. **F 与 W 之间还剩约 5 µs，那是「每次调用还剩的那一次 `append`」，也是这个类公开契约的
   价钱。** `str()` / `data()` / `size()` 都是文档化的观测点，实测语义是「凡是成功写进去
   的，都已经在缓冲里」；再往下省只能写进已分配容量、收尾才 `resize`，那会把「一次调用
   中途读缓冲读到什么」变成另一种语义。要更快就得换一套契约，而不是把这一套偷偷改快。
4. **绝对值别横比，也别拿它预言平台分数**：这是**不起服务**的探针数 —— 它数的是 8 397 B
   的序列化，不是任何一档的 RPS。这一节只说「这一段省掉了一小半」；落到平台上值多少，
   要看**下一轮** `json-*` 三档自己的读数。
5. **改条目的那一步是逐字节等价的**：把条目今天那份 `build_json`（每项 `dump()` 后拼接）
   与换成写出器的那份放进同一个进程，在 `n ∈ {0,1,2,7,23,25,40,49,50,999}` ×
   `m ∈ {0,1,2,6,8,11,999999}` 共 70 组上比对，**输出逐字节相同**（n=999 会被夹到 50）。
   这是「换实现不改产物」的直接证据，不靠肉眼读 JSON。

**改动前后的判据**（比上面那张表更该看的）：`tests/functional/json_writer_func.cpp` 原有
867 行**一字未改**，另加 44 行钉住两条快路的边界（42/43 字节那道界、210 字节长键走回落、
「快路按最坏量拒绝、实际却塞得下」仍然成功），同一批断言在**改动前后双双全绿**；输出在
两版上都是 **8 397 B**、逐字节相同。全套 79 条 `ctest` 改动前后逐条**同名同结果**。


### 4.7 缓存校验跑在哪条线程上（**第六套装置**，平台形状 A/B）

> 第六套装置，但**和上面五套都不是同一支**：它用的是 [`benchmark-rig.md`](benchmark-rig.md)
> 「h1/h2 那三档的 A/B」那一节里的靶场 —— 条目裸机起、命令照抄平台、服务端
> `taskset -c 0-7`、驱动器 `taskset -c 8-15`、两臂交替起停（`0 1 1 0`）。与 4.5 的差别
> 只有一处：4.5 是**平台自己的机器**，这里是本机。**两份臂用的是同一个二进制、同一个
> `.so`**，唯一变的是一个环境变量（`UVCPP_ABL_LOOPSTAT=0|1`）⇒ 任何差异都不可能来自
> 构建 / 链接，只可能来自"那次 `stat` 跑在哪条线程上"。

**要回答的问题**：`static-*` 三档的平台每请求 CPU 是 210 ~ 254 µs，而"把字节搬出去"只
解释其中约 30 µs（4.3 节那支 `shaped` 拟合的斜率 × 16 483 B）。命中的请求每一条仍然
要**投一次线程池**，而 4.3 节的 `ab-pool` 读数把池往返 + 池锁争用定在 **18 ~ 36 µs**。
那么，把命中路径上**唯一**需要池的那一步（重新校验用的那次 `stat`）搬回循环线程做，
值多少？——这里量的是**一条腿的每请求用户态 CPU**，不是任何一档的分数。

**判据一（确定性，不吃压测噪声）：`strace -f -c` 下的系统调用计数。** 同一份
`requests/static-h2-uris.txt`，`-m 4 -c 8 -t 4 -n 4000`，两臂各 4000 个 2xx：

| syscall | `POOL` 臂 | `LOOP_STAT` 臂 | 每请求 |
|---|---:|---:|---:|
| `futex` | 18 037 | **929** | 4.51 → **0.23** |
| `statx` | 4 000 | **4 000** | 1.00 → **1.00（一个不少）** |
| `write` | 4 349 | 1 115 | 1.09 → 0.28 |
| 合计 | 29 605 | **7 425** | 7.40 → **1.86** |

（`write` 那一行不解释：响应体走的是 `writev`，这一行两臂都不是发响应的那条路；把它
留在表里是因为"合计"要落到同一批 syscall 上，删掉它会显得总数掉得比实际更多。）

两格各自说明一件事：`futex` 掉到二十分之一是"**池往返没了**"；`statx` 一个不少是
"**校验照样做**，只是换了条线程" —— 后者才是"语义没变"的证据，光看 `futex` 掉是看不出
这一点的。（`ls -l` / `stat` 那类调用在本代 libuv 上走的是 **`statx`**；第一版 trace
列表里没写 `statx`，于是"计数不变"这条判据看上去不成立 —— 那是量具的错，不是库的错。）

**判据二（性能）：平台形状 `-c 256 -m 32 -D 5s`，每个臂三次取中位数**，读
`cpr.sh` 的 `us_per_req`（`/proc/<pid>/stat` 的 utime+stime ÷ 2xx）：

| 腿 | `POOL` | `LOOP_STAT` | 差 | rps（中位数） |
|---|---:|---:|---:|---|
| `h2tls`（`static-h2` 那条腿） | 84.571 µs | **64.671 µs** | **−23.5%** | 83 543 → 122 721 |
| `h1clr`（`static-tls` 那条腿，明文 h1） | 56.084 µs | **39.448 µs** | **−29.7%** | 125 662 → 200 129 |
| `h2c` | 67.667 µs | **46.481 µs** | **−31.3%** | 100 228 → 171 559 |

**中位数是必须的，不是讲究**：六格原始读数里 `h2tls-r1-ls1` 是 95.996 µs、比同臂的另外
两次（62.384 / 64.671）慢了整整 48% —— 每格的第一次（`r1`）在**所有六个序列里都是最慢的
离群点**（桌面机，第一次跑有冷页表与调频）。三个臂六个序列，中位数那一格才是"这台机器
在稳态下给出的数"；把 `r1` 的 95.996 当成 `LOOP_STAT` 的代表，会得出"h2tls 反而变慢"的
反向结论。

**ticks 那一列旁证了同一件事**：`POOL` 三臂是 3 425 ~ 3 582 ticks，`LOOP_STAT` 三臂是
3 971 ~ 4 031 —— 而 8 个核 × 100 Hz × 5 s ≈ **4 000 ticks 就是天花板**。也就是说 `POOL`
那一侧**根本没把绑给它的 8 个核用满**，空转 10 ~ 14%，而省下来的正是"等池"那段；换成
`LOOP_STAT` 直接顶到天花板（这个方向的推论是：再从这里省，得先退出"每请求一次 `stat`"）。

三条口径要一起写：

1. **默认没变。** 新增的是一个选项 `uvcpp_web_revalidate { POOL, LOOP_STAT }`，默认
   **`POOL`**，也就是 1.6.24 之前唯一的行为；`LOOP_STAT` 要显式开。默认那条路上没有新
   代码被走到：`loop_revalidate()` 为假时进的还是原来那个 `else if (cache_enabled())`
   分支，`probe_job` 里按候选键循环的那一段**一行没动**（`git diff` 可逐行核），上面这张表
   的 `POOL` 臂跑的就是它；把 `POOL` 与 `LOOP_STAT` 的 syscall 列并排看也正是这个意思 ——
   两者差在 `futex` 上，`statx` 一格不差。
2. **`LOOP_STAT` 只在本地盘上合算。** 循环线程上那次 `stat` 是**阻塞**的：ext4 上
   1.35 µs、FUSE / 网络盘上 46 µs 量级 —— 后者会把同一条循环上的其它连接一起拖住，
   尾延迟涨而 rps 看着还行。两个数都写在 `uvcpp_web_static.h` 的选项注释里，盘型不明的
   部署继续用 `POOL`（一个字段回退）。
3. **语义逐字不变。** 两种模式下都是"下一个请求必带新字节"：`LOOP_STAT` 走的还是那一份
   `probe_*` + 缓存比对，只是提前到了 `serve()` 里做；`tests/functional/web_app_static_func.cpp`
   新增的 `loop_stat` 用例把这条钉住 —— 改写文件后**第一个**请求就必须拿到新字节
   （孪生 `.br` 被改写后同理），以及一次命中都不许投池。

**别横比**：这三格是**本机 + 单腿 + 一个旋钮**的读数，`us_per_req` 与 4.5 的平台
`(cpu% × 1e6) / rps` 不是一把尺子；这一节只说"这三条腿各少吃掉 1/4 ~ 1/3 的每请求
CPU"，落到平台上是多少，要看下一轮 `static-*` 三档自己的读数。


---


### 4.8 h3 那条静态腿的同一件事（**仍是第六套装置，换一条腿**）

4.7 量的是 `uvcpp_web_static`（`webapp/` 那份实现）在 **h1/h2** 两条腿上的表现。平台上
还有第三档 `static-h3-64`（QUIC），它走的是**另一份实现** `uvcpp_static_server`
（`web/` 那份，`uvcpp_web_app` 没有 QUIC，h3 上挂静态文件只有这一个选择）—— 所以
4.7 的结论**不能直接搬过去**，得单独量一次。这一节就是那次量测。

**与 4.7 的两处不同，都会改变读数**：

1. 这条腿每请求做的是**两次** `stat`：原文件一次，孪生候选（`app.js.br`）再一次 ——
   20 个 URI 里 15 个有孪生。池往返比 h1/h2 那条腿贵一倍；
2. 但这条腿的每请求 CPU 里有**一大块池往返管不着的**固定开销：QUIC 自己每请求要
   十几次 `sendmsg`/`recvmsg`（下面表里 12.96 + 6.85 = **19.8/req**），那一分钱都省不掉。

**判据一（确定性）：`strace -f -c` 下的系统调用计数。** 平台那条命令照抄
（`h2load --alpn-list=h3 -i requests/static-h2-uris.txt -H "Accept-Encoding: br;q=1, gzip;q=0.8"`），
只把负载压小到量计数够用：`-c 16 -m 16 -t 4 -n 3000`，两臂各 **3000** 个 2xx：

| syscall | `POOL` 臂 | `LOOP_STAT` 臂 | 每请求 |
|---|---:|---:|---:|
| `futex` | 18 830 | **1 984** | 6.28 → **0.66** |
| `statx` | 6 720 | **6 720** | 2.24 → **2.24（一个不少）** |
| `sendmsg` | 38 875 | 38 547 | 12.96 → 12.85 |
| `recvmsg` | 20 543 | 19 420 | 6.85 → 6.47 |
| 合计 | 86 428 | **67 743** | 28.81 → **22.62** |

`statx`/req = 2.24 而不是 1.00，就是上面第 1 条（20 个 URI 里 15 个有孪生 ⇒
`(15×2 + 5×1)/20 = 1.75`，另加每次启动/404 的零头）；**两臂一格不差**才是"校验照样做、
只是换了条线程"的证据 —— 光看 `futex` 掉是看不出这一点的。

**判据二（性能）：平台形状 `-c 64 -m 64 -t 8 -D 5s`，每臂三次取中位数**，读 `cpr.sh` 的
`us_per_req`：

| 臂 | 三次 `us_per_req` | 中位数 | rps（中位数） | ticks |
|---|---|---:|---:|---|
| `POOL` | 121.707 / 125.733 / 131.219 | 125.733 µs | 60 743 | 3 834 / 3 834 / 3 862 |
| `LOOP_STAT` | 116.834 / 125.651 / 117.361 | **117.361 µs** | **68 148** | 4 004 / 4 005 / 4 021 |

每请求 **−6.7%**、rps **+12.2%**。省得比 4.7 那三条腿（−23.5% ~ −31.3%）少，原因就是
开头第 2 条：**这条腿上池往返本来就是每请求 CPU 里较小的一块**。两臂都贴着
8 核 × 100 Hz × 5 s ≈ 4 000 ticks 的天花板（`POOL` 侧 3 834~3 862、`LOOP_STAT` 侧
4 004~4 021），所以这里的 `us_per_req` 差值不是"谁没跑满"，而是同一块 CPU 上少掉的那段
等待 —— 省下来直接换成了多出来的 7 400 rps。

**判据三（尾延迟，4.7 的风险 3 在这里复核）。** 循环线程上就地 `stat` 会阻塞同一条
循环，最坏情况是"rps 看着还行、p99 爆掉"。两臂各多跑一轮（同样的形状），加上
h2load 的 `--log-file` 拿逐请求耗时，只统计 2xx：

| 臂 | 请求数 | p50 | p90 | p99 | max |
|---|---:|---:|---:|---:|---:|
| `POOL` | 290 387 | 63 661 µs | 109 708 µs | 170 526 µs | 358 108 µs |
| `LOOP_STAT` | 337 305 | **56 896 µs** | **86 938 µs** | **140 458 µs** | **307 201 µs** |

尾延迟**变好而不是变坏**：这台机器上语料在 ext4（`/tmp`）上，一次 `stat` 是微秒级，
挪到循环线程省下的那次池往返比它本身贵。⇒ 4.7 的风险 3（"p99 涨 >2× 即证伪"）**没有被
证实**。**但这只说明本地盘这一档**：FUSE / 网络盘上一次 `stat` 是 46 µs 量级，那条路上
同一个旋钮的结论要反过来读（`uvcpp_static_server.h` 的选项注释里两个数都写着），
所以默认档仍是 `POOL`。

三条口径与 4.7 逐字相同，只是换了一份实现和一个类名：**默认没变**（`uvcpp_static_revalidate`
默认 `POOL`，老调用方一行不改）、**`LOOP_STAT` 只在本地盘上合算**、**语义逐字不变**
（两种档都是"下一个请求必带新字节"）。第三条由
`tests/functional/web_static_server_func.cpp` 新增的 `loop_stat` 用例钉住 —— 它除了逐字节
比对七种请求形状（孪生 / 目录 index / 目录步进 / SPA 回退，含那两跳递归）之外，还读**处理函数
返回之后**的 `resp.deferred`：命中与 404 必须是 `false`（就地回完），只有真的落到读盘
那条路才是 `true`。这一格是两档**唯一**不同的地方，也正是"搬回循环线程"这句话的
可执行版本。

**别横比**：这里的 `us_per_req` 与 4.7 那三格**不是同一份实现**（`uvcpp_static_server`
对 `uvcpp_web_static`）、也不是同一条传输，逐格对照没有意义；两节各自只说"自己那条腿
少吃掉多少每请求 CPU"。

### 4.9 命中路径不再整块拷贝（**h3 那条腿 + callgrind 装置**）

> 又是两套装置的拼装：服务端与形状同 4.8（h3 那条腿、`--alpn-list=h3`、`-c 16 -m 64
> -t 8 -D 20s`），读数取 4.3 的 callgrind（每请求指令数）。两臂是**同一个条目二进制、
> 同一份环境**，只换 `LD_LIBRARY_PATH` 指的那份 `.so`：`so-head` 用本改动**之前**的
> `src/web/uvcpp_static_server.cpp` 建，`so-share2` 用改完那份建。**绝对值与 4.3 那张表
> 不可比**（那条腿是 h1 + `gcannon`），跟 4.7 / 4.8 的 µs 也不可比。
>
> **为什么连接数不是 64**：先用平台形状 `-c 64 -m 64 -t 8 -D 5s` 跑了一轮，只有 **136**
> 个 2xx，而 callgrind 表头两位是 `rsaz_1024_sqr_avx2`（36.9%）与 `rsaz_1024_mul_avx2`
> （10.7%）—— 那是**握手的 RSA**：64 条连接各握一次手，摊在 136 个请求上。把连接数压到
> 16、窗口拉到 20 秒之后，握手那两项在两臂里变成**绝对值逐条相同**（`rsaz_1024_sqr_avx2`
> 两臂都是 69 481 344 条），于是它从干扰项变成了对照组。

| 读数（`--alpn-list=h3 -c 16 -m 64 -t 8 -D 20s`） | 2xx | part 2 指令合计 | **每请求指令数** |
|---|---:|---:|---:|
| 改动前（`so-head`） | 5 847 | 1 408 228 282 | 240 846.3 |
| 改动后（`so-share2`） | 6 087 | 1 274 849 946 | **209 438.1** |

⇒ 同一会话内夹逼 **−31 408.2 条/请求（−13.04%）**。

逐函数归因（每请求；`Δ` 那一列是"新 − 旧"）：

| 函数（每请求） | 前 | 后 | 差 |
|---|---:|---:|---:|
| `__memcpy_avx_unaligned_erms` | 72 306.3 | 41 000.8 | **−31 305.5** |
| `malloc` | 3 441.2 | 2 824.9 | −616.3 |
| `_int_free` | 4 919.4 | 4 642.1 | −277.3 |
| `free` | 2 068.7 | 1 931.2 | −137.5 |
| `_int_malloc` | 3 574.9 | 3 543.1 | −31.8 |
| `_aesni_ctr32_ghash_6x`（对照：TLS 那点每字节成本没动） | 29 669.1 | 29 744.7 | +75.6 |
| `rsaz_1024_sqr_avx2`（对照：绝对值两臂相同） | 11 883.2 | 11 414.7 | −468.5（纯分母效应） |
| `_Rb_tree_increment`（反例，见下） | 5 683.4 | 6 180.9 | **+497.5** |

**总量的 99.7% 就是 `__memcpy` 那一行。**

#### 这一节真正该记下来的东西：callgrind 的 `rep movsb` 是**按字节**计费的

上表那个 −13.04% 看上去像"提速 13%"，**它不是**。同一台机器上标定一次就清楚了：

| 标定项 | 读数 |
|---|---|
| 真机 `memcpy` 16 483 B（源在 L2、20 万次、`-O2`） | **73 ~ 80 ns / 次**（215.5 / 227.3 / 207.0 GB/s） |
| 同一段代码放进 callgrind | **16 515 条 Ir / 次**（= 16 483 字节 + 32 条循环开销） |

也就是说 callgrind 把 glibc 的 `memmove-vec-unaligned-erms`（走 `rep movsb`）记成
**每条 Ir 搬运一个字节**，而真机上 16 KB 只要 75 ns（≈215 GB/s，比它"便宜"三个数量级）。
于是那 −31 305.5 条/请求要**先除以字节数才能读**：**31 305.5 ÷ 2 = 15 652.8 B**，正好是
一次响应体的平均字节数 —— 与语料侧 8 000 次请求 131 865 720 B ⇒ 16 483 B/请求（减去
~830 B 的帧与头）对得上。**这一行读作"两次整块拷贝没了"，不能读作"少了 13% 的时间"。**
折成时间：两次 15 653 B 的 `memcpy` ≈ **0.14 µs/请求**，再加省掉的那一次 16 KB
`malloc`/`free`（分配器那一簇每请求共 −1 095 条 Ir），合计 **~0.2 µs**。

⇒ **这一格在 µs 腿上是分辨不出来的**，表就照实贴着、但**不作为证据**：

| 臂 | `us_per_req`（平台形状 `-c 64 -m 64 -t 8 -D 5s`，三轮） | 中位 |
|---|---|---:|
| 改动前 | 116.414 / 123.594 / 124.342 | 123.594 |
| 改动后 | 119.094 / 119.401 / 118.294 | 119.094 |

两臂的 **CPU tick 总量几乎一样**（旧 3 982 / 4 016 / 4 002，新 4 013 / 4 013 / 4 006；8 个核
跑满 5 秒约 4 000 tick），2xx 数的差（旧 321 854 ~ 342 056、新 336 961 ~ 338 647）与轮内散度
同量级 —— 轮内散度 **6.8%**，而被测效应是它的 **1/40**。表里那点"差"是噪声。
（`_Rb_tree_increment` 反而涨了 497.5 条，也是同一件事的旁证：两臂的**混载不是逐字相同的**
—— 快的那一臂在同一个 20 秒窗口里多服务了 4.1% 的请求，于是"随在途流数增长的项"跟着涨。）

#### 确定性判据：指针同一

发出去的字节两种实现**逐字节相同**，所以这件事在网络上、在任何字节比对里都看不出来。
判据只能落在库内部：`test_web_static_server_func` 的 `loop_stat` 用例多了第 8 条 ——
再命中一次 `/app.js` 时，`resp.body` 必须与第 2 条**指向同一个 `std::string`**
（读 `is_shared()` 与 `shared_ref().get()`）。本条改动前那版源码里，两次命中各有各的
`std::string`，指针**不可能**相等。

变异测试：把命中路径改回"先造一份临时响应、再整块赋给调用方"（`ok()` + `out = tmp`），
**6 条断言变红**（第 1 / 3 / 5 / 6 / 7 条的 `body.is_shared()` 为假、第 8 条指针不等），
变异版退出码 **2**、还原版 **0**。

两条配套的机制，都写在头文件注释里、这里只记结论：`uvcpp_buf` 的拷贝构造**是深拷贝且
丢共享态**，而 `uvcpp_http_response` 手写了拷贝构造 / 拷贝赋值 / 析构 ⇒ **没有隐式移动**，
`std::move(resp)` 在类型上就退化成一次深拷贝 —— 这正是改动前那条路上那两次整块拷贝的
来源，也是"共享视图遇到一次拷贝就白共享了"的机制（所以 `get_data()` / `get_udata()`
会 `materialize()`）。

#### 结论（以及它对下一刀的影响）

本条**不是提速**，是"命中路径不再每请求重演一遍整块拷贝 + 少一次 16 KB 分配"：
~0.2 µs/请求（~0.2%）。它值得单独一条提交是因为判据是**确定性**的、语义逐字不变。

真正的信息在反面：**h3 腿的每请求指令数里，`memcpy` 占 19.6% 却几乎不花时间**
（按字节计费的坑），而分配器那一簇 **14 187 条/请求（6.8%）**、AES-GCM/QUIC 每字节那条
路径（`_aesni_ctr32_ghash_6x` **29 745 条/请求**）才是真花钱的地方。⇒ 下一刀砍分配器与
那条每字节路径，**别**继续找"还剩几次整块拷贝"（4.3 那种"`memcpy` 占比最高"的画像在这台
机器上会骗人）。

**补正（2026-10-13，写 4.10 时回头加上）**：上面这句「别继续找还剩几次整块拷贝」是
**就 h3 那条腿**说的，在那条腿上成立 —— h3 腿剩下的整块拷贝是每请求 2 次 ≈ **0.2 µs**，
确实不值得追。**它不能外推**：同一类"整块拷贝"在 h2 两条腿上是响应体的 **4.56× 与 11.17×**，
砍掉其中 40.7 KB/请求换来的是 µs 腿上干净的一格 **−7.4%**（4.10）。⇒ 正确的说法要**分腿**：
h3 腿上拷贝不是问题（那儿的问题是 AES-GCM 与分配器），h2 腿上拷贝**就是**问题。


### 4.10 静态腿的大头：TLS 出口每批两遍整块拷贝（**第七套装置**，`LD_PRELOAD` 精确计费）

> 服务端与混载形状同 4.8 的 h2 支线（20 文件、`-m 32 -c 256 -t 8 -D 5s`），但**读数既不是
> rps 也不是指令数**，是 `memcpy` / `memmove` / `memset` 的**精确计费**（调用次数 + 字节数，
> 按**调用点**分组）。两臂是同一个条目二进制、同一份环境，只换 `LD_LIBRARY_PATH` 里那份
> `libuvcpp.so`。**绝对值与 4.3 / 4.7 / 4.8 / 4.9 都不可比。** 装置与协议记在
> [`benchmark-rig.md`](benchmark-rig.md) 的「用户态拷贝的量具（`memspy`）」一节。

#### 先修装置：上一轮采样器那 34% 是个**假名字**

上一轮用的采样器（`prof.py`：定时抓 PC → 按 `/proc/<pid>/maps` 折成「模块 + 偏移」→ 取该模块里
**最近的前一个符号**）在 h2 两条腿上排第一的都是同一个东西：

| 腿 | 采样器排第一的符号 | 占比 |
|---|---|---:|
| h2 明文 | `libc.so.6:__nss_database_lookup@GLIBC_2.2.5` | 34.16% |
| h2+TLS | `libc.so.6:__nss_database_lookup@GLIBC_2.2.5` | 34.10% |

`__nss_database_lookup` 是 NSS 的名字服务查找，静态腿一次都不该碰到它。真凶是
**`memcpy`/`memmove` 的真实现**（`__memmove_avx_unaligned_erms`）：

| 读数（`ifn2`：读 `/proc/self/maps` 自己算偏移，**不走 `dladdr`**） | |
|---|---|
| `memcpy` 的真实现 | `libc+0x188a80` |
| `memmove` 的真实现 | `libc+0x188a80`（同一个） |
| 它**前面**最近的一个**导出**符号 | `__nss_database_lookup` `libc+0x188040`（相隔 **2 624 B**） |
| 它**后面**下一个导出符号 | `_thread_db_dtv_slotinfo_list_slotinfo` `libc+0x1c5d58` |

⇒ 两者之间是 **247 KiB 没有任何导出符号**的 `.dynsym` 空洞：glibc 把 `memcpy`/`memmove`/`memset`
的 AVX/ERMS 实现放在那里，`.dynsym` 里只留 `memcpy@GLIBC_2.14` 那一类 IFUNC 间接入口。
于是**任何**"最近前一个符号"的解析都会把这一整簇记到 `__nss_database_lookup` 头上：
**数字是对的（用户态拷贝确实占三成多），名字是假的。**
（顺带解释为什么绕不过去：`dlsym(h, "memcpy")` 会**直接穿到**真实现，拿到的是地址不是名字 ——
只能自己算 `maps` 偏移，这就是 `ifn2` 存在的理由。）

采样器还有第二个毛病：它只说得出"**在**拷贝"，说不出"**是谁**发的"。要动刀就得知道
每一字节是哪一行代码拷的。所以这一节换装置。

**装置 `memspy`**（`LD_PRELOAD` 一个 `.so`，**精确计费，不是采样**）：

- 拦 `memcpy` / `memmove` / `memset` / `__memcpy_chk`；
- 按 **`__builtin_return_address(0)`** 分组 —— 分组键是**调用点**，不是被调函数；
  16 384 槽开放寻址表，无锁 CAS 插入（多线程下不丢样本）；
- 每组记 **调用次数 / 总字节 / 四个尺寸档**（`<64` / `<1K` / `<16K` / `≥16K`）；
- `SIGUSR2` 或析构时 dump，前面附一份带 `MSPY_MAP ` 前缀的 `/proc/self/maps`，
  离线用 `resolve.py` 折成「模块 + 符号 + 偏移」。

**它自己的盲区，先说在前面**：GCC 对**编译期长度已知**的小 `memcpy` 会内联成几条 `mov`，
**不经过 `memcpy`** —— 哪怕 `-O0`。自测里 1000 次 16 字节**常量**长度的拷贝**一次都拦不到**，
而同样 16 字节、长度取自运行时的循环全拦到了。⇒ 这张表的**大块是准的**（16 KB 级不可能被内联），
**小碎块会系统性漏**。所以下面只用它读 `≥16K` 那一档，小字节数不参与结论。

#### 同一份工作，三条腿

平台 static 那三档发的是**同一批 20 个文件**，但传输层与实现都不同。同形状各跑 5 秒：

| 腿 | 2xx | `memcpy`/`memmove`/`memset` 总量 | 每请求 | ÷ 响应体 16 483 B |
|---|---:|---:|---:|---:|
| h1 明文（`:8080`） | 347 595 | **942 303 166 B（0.94 GB）** | 2 711 B | **0.16×** |
| h2 明文（`:8082`） | 331 881 | **24 931 603 581 B（24.93 GB）** | 75 122 B | **4.56×** |
| h2+TLS（`:8443`） | 301 863 | **55 584 900 823 B（55.58 GB）** | 184 141 B | **11.17×** |

⇒ 同一份工作，**h2+TLS 比 h1 多搬 59 倍字节**、每请求多搬 **181 KB**；连 h2 明文都已经
是响应体的 4.56 倍。而 h1 那条腿证明**这件事是可以不做的**：它的交付路径
（`uvcpp_tcp_client::write_owned`，370 174 次调用 / 107.4 MB / 均 290 B）**≥16 KB 的拷贝是 0 次**
—— 16 KB 的响应体是**把所有权交给 `uv_write` 走的**，一字节都没拷。

#### 谁在拷：h2+TLS 的逐调用点归因（改动前）

| 调用点 | 调用 | MB | 均 B | ≥16K | 占比 |
|---|---:|---:|---:|---:|---:|
| `std::string` 内部（libstdc++ `0x16872f`） | 1 792 543 | 14 215.8 | 7 930 | 119 077 | 25.6% |
| `std::string` 内部（libstdc++ `0x16a024`） | 7 605 509 | 7 847.3 | 1 032 | 370 739 | 14.1% |
| **`uvcpp_tcp_client::tls_flush_out`（`0x288658`）** | **19 938** | **5 015.6** | **251 562** | **14 665** | **9.0%** |
| OpenSSL 内存 BIO 输出侧（`0x469405`） | 326 462 | 5 025.4 | 15 394 | 295 806 | 9.0% |
| OpenSSL 内存 BIO 输入侧（`0x468eb1`） | 357 225 | 5 025.3 | 14 068 | 295 811 | 9.0% |
| `WPACKET_close`（`0x4d3b69`） | 333 220 | 5 008.9 | 15 032 | 295 806 | 9.0% |
| `uvcpp_h2_session::impl::cb_read_body`（`0x267753`） | 490 795 | 4 990.3 | 10 168 | 184 084 | 9.0% |
| `BUF_MEM_grow_clean`（`0x47289f`） | 323 029 | 4 985.7 | 15 434 | 293 471 | 9.0% |
| `std::string` 内部（libstdc++ `0x168755`，第 9 名） | 2 517 760 | 2 304.4 | 915 | 109 156 | 4.1% |

**`tls_flush_out` 那一行是靶心**：19 938 次调用、每次 **251 562 B**（= 一批密文）、
14 665 次落在 `≥16K` 档 —— 一次调用把**一整批 TLS 密文**从 `tls_out_` 拷进一个新 `uvcpp_buf`，
只为交给 `uv_write`。两个 `std::string` 站点（`0x16872f` 与 `0x168755`）里 `≥16K` 的那一档
（119 077 与 109 156 次、均 ~114 KB 与 ~16 KB）则是**同一批密文在 `tls_out_` 上按 2 倍几何增长
时被反复搬运**的痕迹 —— 16 KB 那个均值正是几何级数里最小的那几步。

其余四行（OpenSSL 内存 BIO 两个方向 + `WPACKET_close` + `BUF_MEM_grow_clean`，各 ~5 GB、
各 ~30 万次 `≥16K`）是**架构性**的：`uvcpp_tls` 把 OpenSSL 的读写 BIO 接在内存缓冲上，
每字节密文因此在用户态多走两趟；`cb_read_body` 是 nghttp2 的数据提供者，每次回一个 16 KB 分片。
这两类**本轮不动**。

#### 修：`reserve` 一次到位 + 整批当共享视图交出去

`tls_flush_out()`（`src/net/uvcpp_tcp_client.cpp`）原来两处各拷一遍：

```cpp
// doc-snippet: fragment — 摘录改动前后的两处，省略号处不是完整翻译单元
char buf[16384]; size_t n;
while ((n = tls_ssl_->take_ciphertext(buf, sizeof(buf))) > 0)
  tls_out_.append(buf, n);                        // ① 从 0 长到 250 KB，每批 2 倍几何增长
...
std::string chunk; chunk.swap(tls_out_);
uvcpp_buf bufcpp(chunk.data(), chunk.size());     // ② 整批再拷一遍，就为了交给 uv_write
```

改成：

```cpp
// doc-snippet: fragment — 同上，摘录
const size_t pend = tls_ssl_->pending_ciphertext();       // 这批多少字节，OpenSSL 自己知道
if (pend > 0) tls_out_.reserve(tls_out_.size() + pend);   // ① 一次分配，零次搬运
...
auto chunk = std::make_shared<std::string>(); chunk->swap(tls_out_);
w->append_uv_buf_view(uv_buf_init(chunk->data(), chunk->size()), chunk);   // ② 借出去
```

用 `reserve` 而不是 `resize` 是有意的：`resize` 会把新露出的那段**清零**，等于每批白清 250 KB。
`append_uv_buf_view()` 是写层**已有的**零拷贝通道（`hold_` 持着 `shared_ptr`、析构时放掉），
`uvcpp_h2_connection::flush()` 的 TLS 支线已经在用同一个机制（`write_buf_->share(pending)`；
明文那条支线在 §4.11 里并到同一条路上）。

#### 确定性判据：每请求拷贝字节（三臂，含一个变异）

同一个 5 秒形状。`t1` = 上面改完那份；`t2` = **只把 `reserve` 那两行去掉、视图保留**的变异臂：

| 臂 | 拷贝总量 | 2xx | **每请求** | 相对 `t0` |
|---|---:|---:|---:|---:|
| `t0` 改前 | 55 584 900 823 B（55.58 GB） | 301 863 | 184 141 B | — |
| `t2` 变异：只要视图、不要 `reserve` | 49 791 493 701 B（49.79 GB） | 297 012 | 167 641 B | −16 500 B（−9.0%） |
| `t1` 改后 | 44 539 030 319 B（44.54 GB） | 310 462 | **143 461 B** | **−40 680 B（−22.1%）** |

这个数**可复现**：另换一轮跑，`t1` 是 42 445 575 223 B ÷ 296 763 = **143 029 B/请求**（−22.3%）
—— 两轮差 0.3%，比任何 µs 读数都稳，所以它够格当判据。

变异臂把两半**分开**了：

- **视图那一半 ≈ 16.5 KB/请求**（`t0 − t2`）。这个数正好是**一次响应体**（16 483 B）的量级：
  一批 251 562 B 的密文摊到约 **15 个请求**上，摊到每请求就正好一个 body。
- **`reserve` 那一半 ≈ 24.2 KB/请求**（`t2 − t1`）。方向也对：几何增长搬的总字节
  ≈ 2 × 终值 × 批数，摊到每请求是 1.5~2 个 body。

两个**互相独立**的确认：

1. `t1` 的归因表里 **`tls_flush_out` 这个调用点整个消失**（`--top 200` 都搜不到）——
   两臂之间唯一的差别就是它不再拷了。
2. `t0` 里那两个 `std::string` 站点 `≥16K` 档的次数（119 077 / 109 156）在 `t2` 里
   **原样回来**（114 859 / 106 468），在 `t1` 里掉到 **53 791 / 39 255**。

#### µs 那条腿：交错三轮，82.1 → 76.0 µs

拷贝字节是判据，时间只当旁证。同形状，`t0` / `t1` **交替**跑、各 3 次：

| 臂 | 三轮 `us_per_req` | 中位 |
|---|---|---:|
| `t0` | 79.869 / 88.258 / 82.068 | 82.1 |
| `t1` | 73.848 / 77.347 / 75.970 | **76.0** |

⇒ **−6.1 µs（−7.4%），3–0，两臂区间无交叠**（`t0` 最低 79.9 > `t1` 最高 77.3）。
40 680 B/请求 ÷ 6.1 µs = **6.7 GB/s** —— 与 4.3 那条 0.16 ns/B（≈6.2 GB/s）的标定落在同一个带里
（省下的还有几何增长那一串 `malloc`/`free`，所以 6.7 是**有效**速率，不等于 `memcpy` 带宽）。

**先记一个自己踩的坑**：第一次跑的是**非交错**两臂（`t0` 全跑完再跑 `t1`），读出来
h2+TLS 是 125.388 → 126.903 µs，看着像 **+1.2% 的倒退**。但同一轮里两条**负对照**也各涨了
+1.6%（h2 明文）与 +1.0%（h1 明文）—— **三条腿一起涨同样的幅度，涨的是机器不是代码**。
改成交错之后，负对照回到一动不动、被测腿掉 7.4%。

#### 负对照：另外两条腿一字节都没动

| 腿 | `t0` | `t1` | 判读 |
|---|---:|---:|---|
| h1 明文 | 942 303 166 B | **942 303 166 B** | **逐字节相同** |
| h2 明文 | 24 931 603 581 ÷ 331 881 = 75 122 B/请求 | 24 660 639 621 ÷ 325 835 = 75 686 B/请求 | +0.75%，噪声内 |

机制上也说得通：`tls_flush_out()` 第一行就是 `if (tls_ssl_ == nullptr) return;`，
h1 / h2 明文两条腿**根本不进这个函数**。

#### 下一刀

h2 明文那条腿的 `uvcpp_h2_connection::flush()` 是同一件事、同一个形状：21 924 次调用、
均 **251 595 B**，占 h2 明文全部拷贝字节的 **22.1%** —— 它就是本节的 `tls_flush_out`
在那条腿上的对应物，只不过那条腿没有 TLS，走的是明文支线的整块拷贝
（`write_buf_ = new uvcpp_buf(pending->data(), pending->size())`）。它**不是 TLS 专属**的，
所以两条腿都能吃到；难点在明文支线今天用 `out_uv_buf()` **接走块的所有权**，
共享视图到那一步会被 `materialize()`，得先把这条交付路径也改成收视图。**§4.11 就是这一刀。**

### 4.11 同一个形状在 h2 明文那条腿：交付路径收视图，`flush()` 的两条分支合并（**仍是第七套装置**）

#### 卡在哪一步

`uvcpp_h2_connection::flush()` 把 `out_` **换**进一份 `shared_ptr<std::string>`（零拷贝），
但交给写层的方式按连接形态二选一：TLS 支线走 `write_buf_->share(pending)`（视图），
明文支线走 `new uvcpp_buf(pending->data(), pending->size())`（**整块拷一遍**）。
明文这一支不能直接照抄 TLS：`uvcpp_tcp_client::write(uvcpp_buf*, cb)` 无条件
`buf->out_uv_buf()` **接走块的所有权**，而 `out_uv_buf()` 对共享视图会先 `materialize()`
—— `uvcpp_buf.h` 自己在那一段写着"它不是错误，是一次白拷贝"。

所以顺序是：**先让交付路径认视图，再合并分支**。判据是 `uvcpp_buf::is_shared()`，
和 `uvcpp_write::adopt_body()`（`src/req/uvcpp_write.cpp:168`）已经在用的**同一条规则**：

```cpp
// doc-snippet: fragment — 摘录 `uvcpp_tcp_client::write(uvcpp_buf*, cb)` 的交付段
uvcpp_write* w = new uvcpp_write();
if (buf->is_shared()) {                       // 共享视图：借出去，别 materialize
  w->append_uv_buf_view(uv_buf_init(const_cast<char*>(buf->get_const_data()),
                                    static_cast<unsigned int>(buf->size())),
                        buf->shared_ref());
} else {
  w->set_uv_buf(buf->out_uv_buf(), true);     // 自有块：照旧接走所有权
}
```

`get_const_data()` 就是 `return this->buf.base;`（`uvcpp_buf.cpp:378`），**不物化**；
`const_cast` 在 C++11 下是必需的（非 const `std::string::data()` 仍返回 `const char*`）。
顺带把这次写的两处 `get_uv_buf()` / `1` 换成 `get_uv_bufs()` / `get_uv_nbufs()`，
于是单块与双块两条路径走同一个出口。改完 `flush()` 的这一段只剩：

```cpp
// doc-snippet: fragment — 摘录 `uvcpp_h2_connection::flush()` 的交付段，改后
std::shared_ptr<std::string> pending = std::make_shared<std::string>();
pending->swap(out_);
write_buf_ = new uvcpp_buf();
write_buf_->share(pending);                   // 两种连接形态同一条路，都不再拷
```

改前那两行是 `if (client_->is_tls()) { … share(pending); } else { new uvcpp_buf(pending->data(), pending->size()); }`。

#### 确定性判据：每请求拷贝字节（被测腿 + 两条负对照）

同一个 5 秒形状，`t1` = §4.10 之后那份（明文支线仍整块拷贝），`t3` = 本次改后：

| 腿 | `t1` | `t3` | 判读 |
|---|---:|---:|---|
| **h2 明文（被测）** | 25 299 542 732 ÷ 336 969 = **75 078 B** | 19 058 017 954 ÷ 323 754 = **58 866 B** | **−16 212 B（−21.6%）** |
| h2+TLS（负对照） | 42 807 865 644 ÷ 298 994 = 143 173 B | 41 511 910 200 ÷ 289 203 = 143 538 B | +0.3%，噪声内 |
| h1 明文（负对照） | 958 011 694 ÷ 354 105 = 2 705.4 B | 937 842 020 ÷ 347 495 = 2 698.9 B | −0.24%，噪声内 |

两条负对照都不该动，机制上说得通：h2+TLS 的 `flush()` 走的是本来就零拷贝的 TLS 支线，
`t3` 没碰它；h1 腿**根本不进** `uvcpp_h2_connection`。

#### 归因表：那一行整个消失

`t1` 里靶心是它（`--top` 表第 2 名），`t3` 里 `--top 400` 都搜不到：

| 臂 | 调用点 | 调用 | MB | 均 B | `≥16K` | 占该腿字节 |
|---|---|---:|---:|---:|---:|---:|
| `t1` | `uvcpp_h2_connection::flush()`（`0x25dd4a`） | 22 638 | 5 599.6 | 247 356 | 15 293 | **22.1%** |
| `t3` | —— | 0 | 0.0 | — | 0 | **0.0%** |

5 599.6 MB ÷ 336 969 = 16 617 B/请求，与被测腿掉下去的 16 212 B/请求只差 2.4%
（余下那点差是同一轮里其它站点各自 +0.5~1% 的漂移 —— 两条负对照身上有同样幅度的漂移）。

一处**看起来像**新出现、其实是同一行的改名：`t1` 第 4 名写作
`std::_Function_handler<…>（0x267753）`、548 755 次 / 5 579.7 MB / 均 10 168，
`t3` 里同一行写作 `uvcpp_h2_session::impl::cb_read_body（0x267713）`、
529 878 次 / 5 383.9 MB / 均 10 161 —— 偏移整体挪了 `0x40`（同一个文件改了代码），
`resolve.py` 取的"最近的前一个符号"跟着变了，实际是**同一个调用点、同一件事**。

#### µs 那条腿：效应落在噪声地板上，如实记

先跑交错 3 轮（h2c 与被测，h2tls 当负对照）：h2 明文 63.5 → 62.9 µs（−0.6），
而**负对照 h2tls 87.5 → 85.9 µs（−1.6）动得比被测腿还多** —— 这一轮的读数分不开信号。
改成 h2 明文单腿**交错 7 轮**：

| 臂 | 七轮 `us_per_req` | 中位 |
|---|---|---:|
| `t1` | 61.2 / 62.5 / 63.4 / 70.0 / 73.0 / 68.1 / 68.7 | 68.08 |
| `t3` | 61.5 / 62.4 / 66.4 / 68.4 / 65.8 / 69.5 / 68.8 | **66.42** |

⇒ 中位数 **−1.66 µs（−2.4%）**，方向与量级都对（16 212 B/请求 ÷ §4.10 标定的
6.7 GB/s ≈ 2.4 µs），但**这一轮证据算弱**：rps 在整轮里从 110 467 单调漂到 96 658
（前 3 轮两臂都在 61~63，后 4 轮都在 66~73），且 7 轮里 `t3` 更快的只有 4 轮。
**判据是字节，不是 µs** —— 这一刀的收益（约 2 µs/请求）就压在 3.5 节那台桌面机的噪声带上。

#### 边界与风险

- **视图存活**：借出去的那块由 `uvcpp_write` 持有的引用计数履行，`flush()` 返回、
  `write_buf_` 在 `on_write_done()` 里被回收都不影响它 —— 与 TLS 支线今天成立的理由相同。
- **自有块的路径逐字节不变**：`is_shared()` 为假的 `uvcpp_buf` 仍走
  `out_uv_buf()` + `set_uv_buf(raw, true)`，一行语义没动。
- **`out_` 的 `swap` 语义不变**：`share()` 对**空**源是 no-op（`uvcpp_buf.cpp:246`），
  所以"没有待发帧就不写"这条边界不受影响。

#### 下一刀

h2 明文这条腿剩下的开销不再是"某一处整块拷贝"，而是散布的构造与几何增长：
`t3` 的归因表里 `std::string` 内部 `0x16872f`（185 万次 / 7 423.9 MB / **39.0%**，
`≥16K` 58 769 次）与 `0x16a024`（796 万次 / 4 380.5 MB / 23.0%），以及 h2 数据提供者
`cb_read_body`（529 878 次 / 5 383.9 MB / 均 10 161 B / **28.3%**）。

> ★ **对 `0x16872f` 的那句猜测（"是 `out_` 上按 2 倍几何增长的痕迹，可用 `reserve`
> 打掉"）在 §4.12 里被实测**证伪**了**：真去 `reserve`，那个站点只掉了自己的 7.3%。
> 剩下两条的归因见 §4.12 末尾。

### 4.12 h2 两条腿的 `out_`：每批从 0 开始几何增长 → 按上一批大小 `reserve`（**仍是第七套装置**）

#### 机制：容量每批都被搬走

`uvcpp_h2_connection::flush()` 走的是 `drain(out_)` —— 而 `drain()` 是把本批帧
**一段一段 `append` 进 `out_`** 的（`nghttp2_session_mem_send2` 每返回一帧就追加一次），
下一句 `pending->swap(out_)` 又把整批**连缓冲区一起**取走交给写层。于是 `out_` 每批都从
`capacity() == 0` 重新开始，按 2 倍几何增长，搬的总字节 ≈ 2 × 终值，再摊上十几次
`malloc`/`free`。

修法是给 `out_` 一个**跨批的容量提示**：同一个连接上批与批高度相关，上一批的大小就是
这一批免费的预测。

```cpp
// doc-snippet: fragment — 摘录 `flush()` 里 reserve 提示的设置点
if (out_hint_ > 0) out_.reserve(out_.size() + out_hint_);   // 一次分配，零次搬运
const int rv = session_->drain(out_);
...
out_hint_ = (pending->size() <= (1u << 20)) ? pending->size() : 0;   // 超过 1 MiB 就不再提示
```

两点**不是**顺手写的：

- **这个提示不会把内存钉在连接上**。`out_` 的缓冲区每批都被 `swap` 进 `pending` 交给
  写层，函数返回时 `out_` 的容量已经回到 0 —— 也就是说这份预留是**一批的生命周期**，
  与改动前的峰值同一个量级。
- **上限 1 MiB** 是为了不让某一次异常大的批把**此后每一次** flush 都撑到那个尺寸
  （退化方向是"回到几何增长"，只会变慢不会变错）。

#### 确定性判据：每请求拷贝字节（两条被测腿 + 一条负对照）

同一个 5 秒形状，`t3` = §4.11 之后那份，`t4` = 本次改后：

| 腿 | `t3` | `t4` | 判读 |
|---|---:|---:|---|
| h2 明文 | 19 410 751 545 ÷ 333 624 = 58 181.5 B | 19 073 238 810 ÷ 336 849 = **56 622.5 B** | **−1 559 B（−2.7%）** |
| h2+TLS | 43 128 475 016 ÷ 301 886 = 142 863.4 B | 43 368 888 691 ÷ 307 601 = **140 990.7 B** | **−1 873 B（−1.3%）** |
| h1 明文（负对照） | 2 701.6 B | 2 706.8 B | +0.19%，噪声内 |

这一刀与 §4.11 不同：**两条 h2 腿都该掉**，因为两条腿的明文侧都要过 `drain(out_)`
（TLS 只在 `tls_flush_out()` 之后才分岔）。负对照依旧不该动，h1 那条腿根本不进
`uvcpp_h2_connection`。

#### 归因表：确实是从 `0x16872f` 那一行抠下来的

| 量 | `t3` | `t4` |
|---|---:|---:|
| `0x16872f` 总字节 | 7 508.5 MB | 6 958.4 MB（**−550 MB**） |
| `0x16872f` 的 `<64 B` 档调用 | 1 780 036 | 1 788 342 |
| `0x16872f` 的 `<1K` 档调用 | 44 633 | **855** |
| `0x16872f` 的 `≥16K` 档调用 | 58 238 | 46 726 |

那个 `<1K` 档掉了 **98%**（44 633 → 855）—— 一批帧在几何增长的头几步就是几十到几百
字节的搬运，正是 `reserve` 该吃掉的那一段。

#### 这一刀同时**证伪**了 §4.11 末尾对 `0x16872f` 的猜测

§4.11 猜它是"每批帧在 `out_` 上按 2 倍几何增长被反复搬运的痕迹"。按那个模型算，
h2 明文那条腿该掉 ~30 KB/请求（2 × 一批 ≈ 2 × 16.6 KB），**实际只掉了 1.6 KB/请求**
—— 就算把整批的增长全算上，也只够解释这个站点的 7.3%。⇒ 那一行的 36.5% **大部分不在
`out_` 上**，猜测作废，别再顺着它找。

#### µs：一轮非交错读数，方向对但只当旁证

| 腿 | `t3` | `t4` |
|---|---:|---:|
| h2 明文 | 112.3 µs | **109.1** |
| h2+TLS | 124.0 µs | **121.8** |
| h1 明文（负对照） | 105.7 µs | 106.8 |

两条被测腿各掉 2~3 µs、负对照反着涨 1 µs，方向自洽；但这是一轮**非交错**读数
（§4.10 记过这个坑：三条腿一起漂时说明漂的是机器），所以这里只当旁证，判据仍是字节。

#### 下一刀（把 §4.11 那两条的归因重写）

h2 明文剩下的 56.6 KB/请求里，两块大的**都不是能顺手砍掉的拷贝**：

- **`cb_read_body` 29.4%（≈16.6 KB/请求，正好一个响应体）** —— 这不是"会话状态又拷了
  一份"：`stash_body()` 从 `1.6.23-dev` 起收的就是**共享句柄**（
  `std::shared_ptr<const std::string>`，引用计数 +1，零拷贝），`ob->data` 已经是视图。
  这 16.6 KB 是 `nghttp2_data_provider2` **接口本身强制**的一次：nghttp2 把一块 `buf`
  交给 provider，要求 provider 把字节填进去（`cb_read_body` 里那句 `memcpy`）。
  绕开它只有一条路 —— 用 `nghttp2_session_send` + send callback 自己组帧
  （`NGHTTP2_DATA_FLAG_NO_COPY` 只在那条路上成立），而本库全库都建在
  `mem_send2` 上。属于架构改动，**本轮不动**。
- **`0x16a024` 25.9%（847 万次调用、均 582 B、`≥16K` 177 448 次）** —— 尺寸像"每帧
  16 KB 的那一层"，但站点落在 libstdc++ 内部，`memspy` 今天只记
  `__builtin_return_address(0)`（调用点），所以归因只能到"某个 `std::string` 操作"。
  要它继续可用，下一步是**多记一层调用点**（`return_address(1)`），而不是接着猜。
- **`0x16872f` 剩下的部分**按上面的证伪**重新归因**（它已经明确不在 `out_` 上）。


### 4.13 静态腿的路径解析不再每请求重来（**第八套装置**，`LD_PRELOAD` 数系统调用）

#### 机制：每个请求一次 `realpath`，而它是一条逐分量的 `lstat`

`uvcpp_web_static` 判"这个落点在不在文档根内"用的是
`web_resolve_within_root()` —— 它必须展开符号链接，所以每个请求都少不了一次
`realpath`。`realpath` 在 glibc 里是**沿路径逐分量 `lstat`**（而且那些 `lstat`
走的是库内部符号，外部探针看不见），于是它是这条热路径上最大的一笔文件系统开销。

修法是把上一次的解析结论记下来：展开后的绝对路径 `fs_path` 加上
`(st_dev, st_ino)`。命中时只做**一次 `stat`** 比对指纹，不再 `realpath`。
关键的一步是**负数结论也要记**：没有孪生文件的资源每请求都要试
`url + ".br"` / `url + ".gz"` 这两个**注定失败**的候选，只记正数的那一版实测
`realpath`/请求只掉到 0.980。

```cpp
// doc-snippet: fragment — 摘录 `probe_leaf()` 的快路径（省略负数分支）
const resolve_hint* h = find_hint(cfg.resolve_memo ? hints : nullptr, url);
if (h != nullptr) {
  if (h->exists) {
    uint64_t dev = 0, ino = 0;
    if (stat_real(loop, h->fs_path, out.is_dir, out.mtime_sec, out.mtime_nsec,
                  out.size, &dev, &ino) && dev == h->dev && ino == h->ino) {
      out.fs_path = h->fs_path;      // 指纹没变 ⇒ 当初"在根内"的判断仍然成立
      out.status = probe_status::OK;
      return out.status;
    }
  }
  ...
}
```

#### 确定性判据：每请求的文件系统系统调用次数（三臂）

`strace` 在这台机器上用不了（`ptrace` 被禁），而且它自己的减速会改变量到的形状。
这里用的是 `LD_PRELOAD` 一个探针：拦 `syscall()` 并解出 `SYS_statx` /
`SYS_newfstatat` / `SYS_openat` / `SYS_readlinkat`，另外拦 `lstat`/`stat`/`readlink`/
`realpath`。**glibc 的 `realpath` 内部走的是 `__lstat64`/`__readlink`，外部拦不到**
（实测：单独跑 1000 次 `realpath`，其余计数器全 0）—— 它便宜不了，只是这把它量的是
**调用次数**而不是它内部的 `lstat` 次数，这一点写在口径里。

同一个入口二进制、只换 `libuvcpp.so`，先 4000 请求热缓存，窗口 20 000 请求、每臂
两轮（20 个 URL 的混载，`-c 256 -m 32`，ext4 语料）：

| 臂 | 库 | 入口 `resolve_memo` | `realpath`/req | `statx`/req | 小计/req |
|---|---|---|---:|---:|---:|
| C（改动前的整对） | 旧 | — | 2.734 / 2.734 | 2.245 / 2.245 | 4.994 / 5.033 |
| D | 新 | `true`（默认） | **0.001 / 0.001** | 2.245 / 2.245 | **2.285 / 2.272** |
| E | 新 | `false` | 2.734 / 2.734 | 2.245 / 2.245 | 5.013 / 4.993 |

E 是**关掉那个开关**的同一份库，它逐列等于 C ⇒ "关掉 = 回到不做记忆时"是量出来的。
`statx` 一模一样是设计如此：慢路径本来也要 `stat` 一次拿 mtime/size，快路径那次
指纹 `stat` 是把它**换掉**而不是加上去。

#### 这些数还对得上一个按 URL 拆开的模型

只放一个 URL 的请求表再量一遍：带孪生文件的（`app.js`）是 `2 realpath + 2 statx`，
没有孪生的（`bold.woff2`）是 **`5 realpath + 3 statx`**。多出来的那几次不是噪声 ——
`web_real_path(allow_missing=true)` 在整条路径 `realpath` 失败之后**还要再解析一次
父目录**（`src/webapp/uvcpp_web_util.cpp:894-894`、`src/webapp/uvcpp_web_util.cpp:911-911`），所以一次**失败**的解析是 2 次 `realpath`
而不是 1 次。加权 `(15×2 + 5×5)/20 = 2.75` 对 `(15×2 + 5×3)/20 = 2.25`，与上面
实测的 2.734 / 2.245 对上（差的那点是混载里连接建立期的零头）。

#### 变异：把指纹比对去掉，必须红在**内容**上

`test_resolve_hint()` 把 `/hintdir/a.txt` 正常服务一次（烧进记忆），然后把
`/hintdir` 换成**指向根外的链接** —— 路径文本一个字都没变。把
`(dev == h->dev && ino == h->ino)` 改成恒真之后：**2 条红**，其中一条是
`响应体里出现了 [OUTSIDE-AFTER-DIR-REPOINT]`，也就是说根外那个同名文件的字节真的
发出去了。这正是这条判据必须落在内容上的原因：只比状态码的话，"换向没换成功"与
"挡住了"给出的都是非 200。

#### µs：这台机器分辨不出来，只声称"没劣化"

平台 static-h2 形状（`-c 1024 -m 32`）按 C D E E D C 的顺序各跑 4 轮取中位数：

| 臂 | `us_per_req`（中位数） | 四轮的散度 |
|---|---:|---|
| C | 92.2 µs | 82.5 – 97.9 |
| D | **87.9 µs** | 84.2 – 89.7 |
| E | 98.1 µs | 91.3 – 101.4 |

D 最低，但**同一臂内部的散度（±8%）比臂间差还大**（C 的四轮从 82.5 抖到 97.9）。
2.73 次 `realpath` 在 ext4 上按 §4.4 的单文件消融折算只有几微秒量级，正好落在这台
机器在这个形状上的噪声底线以下。所以能声称的只有"没劣化"，判据仍然是上面那张
系统调用表。

#### 已知且接受的一处行为差异

路径的落点被整体搬到根外、原位留下一个指向**同一个 inode** 的链接时
（`mv` 到根外 + `ln -s` 回原位），指纹不变 ⇒ 命中路径继续按原 URL 服务它，而完整
解析会判越界。差别是"曾经被授权过的那份字节多活一会儿"，不是读到没被授权过的字节：
`rm` 立即生效，`validate.sh` 的 staleness 探针用 `mv -f` 换文件（inode 必变）也不
受影响。要绝对严格就把 `resolve_memo` 关掉（一个字段，代价回到 C 那一行）。

#### 下一刀

`statx`/请求 **2.245 一格没动**，而它现在是这条腿剩下的最大一笔系统调用（小计
2.28 里有 2.245 是它）。它的构成是"主文件一次 + 每个候选孪生一次"：命中孪生的 URL
是 2 次，没孪生的是 3 次（两次注定失败的候选各一次 `lstat`）。要再往下压就得动
**负结果的粒度**（比如把"这个目录下没有 `.br`/`.gz`"并成一次判断），那是另一条刀。


---


### 4.14 h2 每批最多吐 64 KiB：`static-h2` 的 2.7 GiB 是从「批次大小」里来的（**第九套装置**）

#### 机制：一批有多大，由**对端通告的窗口**决定，不由本库决定

`uvcpp_h2_connection::flush()` 最早是「把 nghttp2 里所有就绪的帧一次榨干」，然后整块交给
`uvcpp_tcp_client::write()`。榨多少是 `nghttp2_session_mem_send2()` 说了算，而它的出站
字节量上限是**对端通告的窗口**：`h2load` 的 `-w`（流窗口）与 `-W`（连接窗口）默认都是
`30`，也就是 2^30−1 ≈ 1 GiB。

于是平台那一格（1024 连接 / `-m 32`）下，服务端会把一条连接上**所有**就绪的响应体攒成
一批推出去。一批 = 32 条流 × 约 16.5 KiB ≈ **500 KiB**，而它同时存在于三个地方：

1. `session_->drain(out_)` 攒出来的那一批明文（`out_.reserve` 出来的 `std::string`）；
2. `flush()` 里 `make_shared<std::string>` + `swap` 之后挂在 `pending` / `write_buf_`
   上的同一批，一直活到 `on_write_done()`；
3. `SSL_write` 把它拷进写 BIO 的 `BUF_MEM` —— 链路是
   `ssl3_write_bytes` → `tls_retry_write_records` → `BIO_write` → `mem_write` →
   `BUF_MEM_grow_clean` → `CRYPTO_clear_realloc`。

第 3 条是常驻的那一条：**`BUF_MEM_grow_clean` 只增不减**，一条连接历史上最大的一批
就是它此后一直占着的容量。1024 条连接 × 约 500 KiB × 2（明文 + 密文）就是量级。

#### 判据一：峰值时刻的活堆归因（抽样，只用于排序）

压测第 25 s（`h2load` 仍在跑）给服务端发 SIGTERM，预载的 `libjemdump.so` 在信号处理器里
调 `mallctl("prof.dump")` 再 `_exit(0)` —— 于是 dump 落在**峰值**上。采样率
`lg_prof_sample:19`（512 KiB），`addr2line` 按 `/proc/<pid>/maps` 的模块基址符号化。

改动前，活堆 **816.8 MiB**，排下来只有两条：

| 栈 | 字节 | 占比 |
|---|---|---|
| `BUF_MEM_grow_clean` ← `mem_write` ← `BIO_write` ← `SSL_write` | 470.0 MiB | 58% |
| `uvcpp_h2_connection::flush()` 里的那一批（`out_.reserve`） | 344.3 MiB | 42% |
| 其余全部（合计） | < 1 MiB | <1% |

**这不是泄漏。** 压测停下 5 s 之后再 dump 一次，活堆只剩约 18 MB —— 连接关完就没了。
RSS 不回落是分配器的保留页（glibc arena / jemalloc `MADV_FREE` 衰减），
按轮次看 RSS 单调上涨（1691.9 → 2801.1 → 3425.0 MiB）是**分配器高水位棘轮**，不是活对象。

旁证（窗口消融）：把 `h2load` 的窗口降到 `-w 16 -W 16`（64 KiB），同一形状的
VmHWM 从 2807.9 MiB 掉到 586.4 MiB，而 `-w 20 -W 20`（1 MiB）仍是 2908.3 MiB ——
自变量确实是「一批多大」，不是「请求多大」。

#### 判据二：修完之后的精确账（`mallctl`，无抽样误差）

改法只有一处：`uvcpp_h2_session::drain(std::string& out, size_t max_bytes = 0)` 多一个
上限，`uvcpp_h2_connection::flush()` 传 `k_max_drain_batch = 64 KiB`。断点**只判「攒够
没有」，不切帧**：`mem_send` 一次给一整帧，而「没榨完的留在 nghttp2 自己的出站队列里」
本来就是合法状态（下一次 `drain()` 接着吐）。所以一批最多超出上限**一帧**。

同一形状（c1024 / `-m 32`）、同一时刻（t=25 s）、同一条 30 s 压测，读分配器自己的账：

| 指标 | 改动前 | 本版 | 变化 |
|---|---|---|---|
| `Allocated`（活堆） | 1472.8 MiB | 382.0 MiB | **−74.1%** |
| `active` | 1551.0 MiB | 451.6 MiB | −70.9% |
| `metadata` | 30.9 MiB | 26.9 MiB | −13.0% |
| `resident` | 2206.4 MiB | 634.4 MiB | −71.3% |
| `mapped` | 2266.5 MiB | 698.4 MiB | −69.2% |
| `retained`（脏页） | 902.5 MiB | 319.6 MiB | −64.6% |
| `VmRSS`（同一刻） | 2054.9 MiB | 583.5 MiB | −71.6% |

另一套口径（只用内核的 `VmHWM`，不预载 jemalloc；每形状先跑一轮热机丢掉）：

| 形状 | 改动前 HWM | 本版 HWM | 改动前 rps | 本版 rps |
|---|---|---|---|---|
| A `static` c1024 `-m 32`（平台形状） | 2890.3 MiB | **724.1 MiB** | 63,366 | 71,158 |
| B `static` c1024 `-m 1` | 492.6 MiB | 436.1 MiB | 42,896 | 47,661 |
| C `static` c256 `-m 32` | 766.0 MiB | **215.6 MiB** | 63,584 | 69,029 |
| D 非静态 c1024 `-m 32`（地板） | 144.2 MiB | 145.1 MiB | 582,836 | 620,825 |

D 那一行是**对照臂**：它不经过静态处理器，两臂的 HWM 只差 0.6%，而 rps 也有 +6.5% ——
也就是说四个形状里普遍存在一个「后跑的那一臂更快」的机器漂移，rps 的涨幅不能全部记在
这一刀头上。**内存那条线不受影响**：A/C 掉的是 4 倍与 3.6 倍，D 一格没动。

#### 判据三：CPU 上不花钱（配对 A/B）

饱和档的 rps 量的是「谁先撞墙」，跨轮不可比；同一臂连着跑三遍，臂内极差就有 9%，
足以把改动的效果整个盖掉。所以改成**交替**起服务（改动前 / 本版 轮流，各 3 轮 × 3 次读数），
只看**同一轮里两臂的差**：

| 轮 | 改动前 µs/请求 | 本版 µs/请求 | Δ |
|---|---|---|---|
| 1 | 118.16 | 115.60 | −2.56 |
| 2 | 97.67 | 93.47 | −4.20 |
| 3 | 93.82 | 92.98 | −0.84 |

**配对差中位 −2.24 µs/请求**（口径：`/proc/<pid>/stat` 的 (utime+stime) ÷ 该轮 2xx 数）。
三对里本版全部更省 —— 封顶没有代价，方向上还略好（少一次大块 `memcpy` 与少一轮分配器
增长）。

#### 剩下的那一块，以及为什么不动它

封顶之后写 BIO 那一栈**仍然是剖析里最大的单条**（约占采样总量的 60%），只是绝对值掉了
一个数量级：现在每连接的发送缓冲封在 64 KiB，而残余的每连接约 373 KiB 里，大头是
**每连接固定缓冲**（TLS 16 KiB 读 + 16 KiB 写 + nghttp2 出站 buf，约 56 KiB/连接，
见剖析里 `tls_setup_read_buffer` / `tls_setup_write_buffer` / `nghttp2_bufs_init3`
三条各占约 4.5 MiB 缩放值）与分配器保留（`resident − allocated` = 252 MiB）。
不是某一次拷贝。

**没有**再做「写 BIO 排空后换一个 `BIO_s_mem()`」：那最多省 64 KiB × 1024 ≈ 64 MiB
（HWM 的 ≤9%），代价是给 TLS 写路径加一条新的失败模式。按「只动占比最大的那块」的
口径，这块已经被上一刀吃掉了。

#### 一句关于这把尺子的话

jemalloc 采样剖析的**绝对量不能当尺子**：同一份 dump 按它自己存的缩放值求和，
比同一时刻的 `Allocated` 低 3.5×（`lg_prof_sample:16`）到 9.7×（`:19`），而两个
采样率之间又彼此对不上。所以本页一律**用剖析看排序、用 `mallctl` 看总量**；
两张表不要混读。

#### 复现

```bash
# 精确账（峰值时刻 SIGTERM → malloc_stats_print + prof.dump）
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2:$JEM/libjemdump.so \
  MALLOC_CONF=prof:true,prof_active:true,lg_prof_sample:19,prof_prefix:$JEM/peak \
  JEMSTATS=$JEM/stats.txt UV_THREADPOOL_SIZE=64 <server> &
h2load -i static-h2-uris.txt -H 'Accept-Encoding: br;q=1, gzip;q=0.8' \
  -c 1024 -m 32 -t 8 -D 30s &
sleep 25 && kill -TERM <pid>
```

量具在仓外（`/tmp/arena-run/phase7/`：`jempeak.sh` / `jemsym.py` / `memshape.sh` /
`cpuab2.sh`），**不随仓库发布**；这一节记的是读数与口径，不是脚本。


### 4.15 静态整读的名额是在哪根线程上还的：`static-h2` 那批假 503（**第十套装置**，仓内确定性用例 + 交替 A/B）

#### 机制：名额的持有时长被「循环线程有多忙」决定了

工作池闸门（`uvcpp_web_work_limit`，见 `src/webapp/uvcpp_web_work_limit.h`）封的是
「**并发的磁盘读**」。可是 `1.6.42-dev` 之前，静态整读那条路是这么记账的：

    loop 线程      acquire_slot() 之前先投池
    worker 线程    read_job()：取名额 → 读盘
    loop 线程      after_work()：还名额

**还名额那一步跑在循环线程上，而循环线程正是高负载下最忙的那一根。** 于是名额的持有
时长不是「读盘要多久」，而是「读盘要多久 **+ 从读完到循环线程轮到 `after_work`**」。
压满的时候后一项远大于前者：`in_flight` 顶到上限（`UV_THREADPOOL_SIZE=64` 时是
`64 × 4 = 256`），真正在读盘的只有 ≤ 64 个，后来者一律被 `503 + Retry-After` 回绝。

这不是新病理，是**同一个病理的第二条路**：分片那条路 2026-09-24 已经改成「按块借还」
（`1.3.6-dev`，见 `uvcpp_web_file_transfer::set_chunk_gate()`），当时服务端日志的现场
是 `工作池已满（在途 0 / 16）` —— **在途 0 却拒绝**。整读这条路的现场是
`工作池已满（在途 256 / 256）`，两行日志说的是同一件事：**账面上的"在途"与实际并行
度脱钩了**。

#### 修法：记账搬到 worker，派发留在 loop 线程

「在 worker 上直接 `release()`」是**不安全**的：唤醒回调必须跑在**注册它的那根线程**
上，而现有两个注册方（`src/webapp/uvcpp_web_file.cpp` 的分片块闸门 → `resume()`、
`src/webapp/uvcpp_web_upload.cpp` → `on_slot_available()`）回调里都要续做 loop 上的
I/O —— 从 worker 里同步派发等于让它们跑在 worker 上，那是数据竞争。

所以把闸门的「记账」与「派发」拆开：

| 入口 | 记账 | 派发 | 在哪根线程上调 |
|---|---|---|---|
| `release()` | 当场 | 当场 | 唤醒回调所属的那根（= 注册它的那根） |
| `release_deferred()` | 当场 | **不派发** | 任何线程（worker 就是这一支） |
| `dispatch_wakeups()` | —— | 派发 | 只在唤醒回调所属的那根 |

`run_job()` 在 worker 上读完**当场** `release_deferred()`，同一笔任务在 loop 线程上的
`after_work` 补那一刀 `dispatch_wakeups()`。语义上有一处要紧的地方：**不会丢唤醒** ——
等待者只在「在途数已达上限」时才注册，那一刻必然至少有一个在途任务还没还过名额，它
结算时的检查必在注册之后 ⇒ 一定看得见这个等待者。

#### 判据一（确定性，不吃压测噪声）：仓内两组用例，且**变异必须变红**

`tests/functional/web_app_worklimit_func.cpp` 新增两组：

- `release_deferred_split` 钉闸门自身：账要**当场**记上；`release_deferred()` 的栈上
  **不许**发生派发；满员时两种还法都不许叫（无效唤醒风暴）。
- `worker_release_flushed_by_after_work` 钉**接线**（`uvcpp_web_static` 到底有没有照
  这套契约用）：上限压到 1，测试线程占住那唯一的名额，让一条**分片**请求停在块边界上
  并登记唤醒（`wakeup_count() == 1`，有界轮询，这是前提断言）；然后测试线程故意
  **只** `release_deferred()` 不补派；再让一个**冷文件**的整读请求去打整读挂载点 ——
  它 worker 里那次 `release_deferred()` 与 `after_work` 里那一刀是**唯一**还能叫醒那条
  分片传输的东西（它自己一个名额都没占、池子里也没有别的活儿）。

**变异实测**：把 `after_work` 里那两行删掉 ⇒ 该组 2 条红
（`整读那次 after_work 的补派必须叫醒挂住的分片请求`、`被唤醒之后那条一次性条目应当
已被消费掉`）。这一条比红本身更重要：**在这个组存在之前，"接线漏了补派"没有任何用例
盖得住**，而它的症状不是慢一点，是那条响应**再也不来**。

#### 这把尺子上的一处坑（如实记）

第一版用例把红绿判在「A 的 `send_wait(req, resp, 8000)` 超时返回非 0」上。实测
**那个超时不生效**：`uvcpp_http_client.h` 写明它靠 Windows 的
`SO_RCVTIMEO`/`SO_SNDTIMEO` 实现、POSIX 上「传入的值会被忽略」，单独验过一遍 ——
`send_wait(req, resp, 1500)` 对着一个从不回包的 socket 卡了 20 s 以上。于是变异下用例
是**挂住**（要等 ctest 的超时才发现、现场什么都不说），不是变红。改成：判定用有界轮询
（`a_replied`），A 那条线程等 `app.stop()` 关掉连接之后自然返回，那时才 `join()`。

#### 判据二：交替 A/B（**只认同一轮里两臂的差**）

形状同 §4.14 那一格（1024 连接 × `-m 32`、20 个静态 URI、`br;q=1, gzip;q=0.8`、
`UV_THREADPOOL_SIZE=64`、ext4 语料），但**只跑 20 s 且交替起服务**：改动前 / 本版
轮流、各 3 轮，读的是 `h2load` 自己那行状态码计数。

| 轮 | 改动前 5xx | 本版 5xx | 改动前 2xx | 本版 2xx |
|---|---|---|---|---|
| 1 | 17,883 | 0 | 1,663,894 | 1,643,319 |
| 2 | 14,747 | 0 | 1,648,941 | 1,638,128 |
| 3 | 15,126 | 0 | 1,635,661 | 1,658,477 |

5xx 那一栏的方向是**干净的**（≈2xx 的 **0.94%** → 0）；2xx 那一栏在噪声内，**不要**
拿它说事 —— 先单跑一轮看到 −2.5% 就当成劣化，交替三轮才知道那是漂移（第 3 轮反而是
本版多）。0.94% 听着不大，但它是同一台服务在同一形状下的**稳定拒绝**，不是抖动；
这一刀同时让名额早一拍变松（后来者不必再等那根最忙的线程）。

#### 复现

```bash
# 判据一：仓内，一条命令
build-all/tests/functional/test_web_app_worklimit_func            # 全组
build-all/tests/functional/test_web_app_worklimit_func worker_release  # 只跑第 16 组
# 变异：删掉 src/webapp/uvcpp_web_static.cpp 里 after_work 那段 if (j->slot_deferred)…

# 判据二：交替起服务，每次换同一份 LD_LIBRARY_PATH
taskset -c 0-7 env UV_THREADPOOL_SIZE=64 LD_LIBRARY_PATH=$LIB <server> &
taskset -c 8-15 h2load -i static-h2-uris.txt -H 'Accept-Encoding: br;q=1, gzip;q=0.8' \
  -c 1024 -m 32 -t 8 -D 20s
```

量具脚本在仓外（`/tmp/wl/ab503.sh`），**不随仓库发布**；这一节记的是读数与口径。


### 4.16 第三个编码器（`br`）：它换的是线上字节，而"换得值不值"取决于有没有 `cache_tag`（**第十一套装置**，仓内微基准 + 自建服务的交替 A/B）

这一节记的是 `1.6.48-dev` 那条可选开关 `UVCPP_ENABLE_BROTLI`（**默认关**）。
放在这一页是为了把口径钉死：**它不是一条提速改动**，判据是"① 线上字节更少、
② 解压回来逐字节相同"，而它到底值不值，要拿平台 `json-comp` 的计价公式算。

#### 机制：两条编码走的是同一条命中路径，编码名只在键里

`uvcpp_http_server::apply_compression_for()` 的变体缓存键是
`编码字符 + 档位字符 + cache_tag`（`src/web/uvcpp_http_server.cpp:2178-2181`）。
命中时只做一次 `std::map` 查找 + 一次 `shared_ptr` 递句柄 —— **gzip 与 `br` 是
同一条路径**。所以"开 `br`"在此处的代价是**每个 tag 一次**，不是每请求一次；
反过来说，响应没有 `cache_tag` 时它每请求重压，而 `br` 的编码比 deflate 贵得多。

#### 读数一：线上字节（三份真实语料，同一份 `libuvcpp_a.a`）

语料是平台 `json-comp` 那条 round-robin 的三个真实响应体，与条目
`build_json()` 的产物逐字节相同：

| 形状 | 原文 | gzip L6 | deflate L6 | **br q5** | br q0（缺陷档） |
|---|---:|---:|---:|---:|---:|
| `/json/25?m=4` | 4 190 B | 961 B | 949 B | **847 B**（−11.9 %） | 1 202 B（+25.1 %） |
| `/json/40?m=8` | 6 707 B | 1 313 B | 1 301 B | **1 168 B**（−11.0 %） | 1 685 B（+28.3 %） |
| `/json/50?m=6` | 8 397 B | 1 546 B | 1 534 B | **1 370 B**（−11.4 %） | 2 007 B（+29.8 %） |

百分比相对 gzip L6。q0 那一列是**缺陷**不是选项：服务器把 `compress_level()`
（默认 `-1`）原样喂给四参数那份 `compress()`，而 `clamp_brotli_quality(-1)` 当时
收成的是 `k_brotli_quality_min` = 0（"最快档"）而不是默认档 5 —— 也就是说"开 `br`"
会真的把响应**压大** 25~30 %。修法是一行哨兵（负数 = 该 method 自己的默认档），
用例里用一段**不对称**断言钉住：默认档那份必须与显式 q5 逐字节相同，**且 q0 必须
严格更大**。

#### 读数二：每请求代价，以及 `cache_tag` 开关把它乘到哪儿去

微基准（`-O2`、预热 20 次后取 4 000 次平均、`taskset -c 2`，同一进程内交替压
同一份 `8 397 B`）：gzip L6 **39.9 µs**、`br` q5 **144.7 µs**（**3.6×**，
`/json/40` 那份是 30.0 → 121.8）。

自建服务的交替 A/B（`uvcpp_web_app` 起在 ext4 语料上、64 条 h1 连接、
每臂 5 轮 × 200 000 次、`taskset -c 0-3`、三个 round-robin URI 轮转，
服务端是**同一份二进制**，只差客户端报不报 `br` 与 `/json` 填不填 `cache_tag`）：

| `/json` 填 `cache_tag` | `Accept-Encoding` | µs/请求（5 轮中位） | 线上字节/请求 |
|---|---|---:|---:|
| 是 | `gzip` | 8.85 | 1 498.9 B |
| 是 | `gzip, br` | **8.55** | **1 350.9 B**（×0.901） |
| 否 | `gzip` | 51.60 | 1 498.9 B |
| 否 | `gzip, br` | **88.60**（×1.72） | 1 350.9 B（×0.901） |

两件事一起读：

- **填了 `cache_tag`**：`br` 与 gzip 的差（8.55 vs 8.85 µs）落在轮次之间的散布里 ——
  命中路径上它不比 gzip 贵，而字节少 9.9 %。按平台
  `eff = rps × (min_bpr / bpr)²` 算，字节那一项是 **×1.23**。
- **没填 `cache_tag`**（也就是**今天条目的形状**：`handle_json()` 不填）：3.6× 的
  编码代价直接落到 rps 上，`eff` 变成 `0.58 × 1.23` = **0.72**，**倒扣 28 %**。

所以这一条不默认开、而且**库侧只落一半**：`br` 是库的能力，要不要在某个条目上开
属于那个条目的判断，前提是它先把响应体的指纹写进 `cache_tag`。

#### 复现

```bash
# 判据一：仓内，两条命令（新断言都在这个 ctest 名里）
build-all/tests/functional/test_web_http_client_func     # compress_brotli / accept_encoding_no_zlib / …
build-all/tests/functional/test_web_app_static_func      # 静态腿那张表里的 br 变体
# 四个构建格（默认关的那两格必须逐字不变）
cmake -B /tmp/cfg-00 -DUVCPP_BUILD_WEB=ON -DUVCPP_BUILD_WEBAPP=ON
cmake -B /tmp/cfg-01 -DUVCPP_BUILD_WEB=ON -DUVCPP_BUILD_WEBAPP=ON \
      -DUVCPP_ENABLE_ZLIB=OFF -DUVCPP_ENABLE_BROTLI=ON
cmake -B /tmp/cfg-10 -DUVCPP_BUILD_WEB=ON -DUVCPP_BUILD_WEBAPP=ON -DUVCPP_ENABLE_ZLIB=ON
cmake -B /tmp/cfg-11 -DUVCPP_BUILD_WEB=ON -DUVCPP_BUILD_WEBAPP=ON \
      -DUVCPP_ENABLE_ZLIB=ON -DUVCPP_ENABLE_BROTLI=ON

# 判据二：仓外那条交替 A/B —— 它自己起停服务，客户端只换报不报 br
# （64 条 h1 连接、每臂 20 万次、三个 round-robin URI 轮转；
#   服务端用 CACHE_TAG=0|1 选填不填 cache_tag）
taskset -c 0-3 /tmp/brq/rig/run3.sh    # 逐臂读 /proc/<pid>/stat 的 utime+stime ÷ 2xx
```

字节/µs 那两张表的量具在仓外（`/tmp/brq/meas/m.cpp` 微基准、
`/tmp/brq/rig/run3.sh` 交替 A/B 与读 `/proc/<pid>/stat` 的 `cpr.sh`），
**不随仓库发布**；这一节记的是读数与口径。
> **后记（§4.17）**：这一节读数二那把尺子里的 `br` q5 每请求 141.68 µs、缺页 220.24 次/次，
> 后来被查出主因是**编码器状态每请求重建**时那 ~728 KB 被 glibc 交还内核再缺页拿回；改成线程
> 本地竞技场之后同一把尺子上是 **88.57 µs、缺页 0.000**（`br`/`gzip` 由 3.252 掉到 1.780）。
> 上面那两张表是**改动前**的读数，原样保留。

### 4.17 brotli 每请求重建的那份状态：要的内存改从线程本地竞技场里发（**第十二套装置**，`/proc` 两行 + 仓外微基准）

#### 机制：状态复用不了，但**它要的那块内存**可以

§4.16 把 `br` 的代价归到「每请求重编一遍」，没有往下问「重编一遍为什么比 gzip 贵这么多」。
往下问一层就碰到一次**状态的生灭**：deflate 那一支**可以**跨请求复用（`static thread_local
deflate_slot`，`deflateReset()` 拨回起点），brotli **不行** —— 它根本没有
`BrotliEncoderReset()` 这个函数，所以每请求都要
`BrotliEncoderCreateInstance()` / `BrotliEncoderDestroyInstance()` 走一整遍。

仓外探针直接挂 `alloc_func` / `free_func` 数出来的这一遍（正文 10 446 B、q5）：一次生命期
**25 块、合计 728 193 B**，其中**两块正好 262 144 B**、一块 125 616 B —— 就是这三块让
glibc 把它们发到 mmap 区（默认阈值 128 KiB），`free` 时 munmap 还回去。于是**每个请求都把
同一批页交还内核、下一个请求再缺页拿回来**。探针里把竞技场缩小到装不下那两块，数字立刻分叉：

| 探针里的发法 | µs/次 | 缺页/次 | 回落块数 | 竞技场内块数 |
|---|---:|---:|---:|---:|
| `std::malloc`（=改前的形状） | 110.79 | **46.00** | 0 | 0 |
| 竞技场 256 KiB | 106.71 | **43.01** | 2 | 23 |
| 竞技场 512 KiB | 59.27 | 0.03 | 1 | 24 |
| 竞技场 1 MiB | 64.75 | **0.03** | 0 | 25 |

256 KiB 那一行只漏掉那两块，缺页就回到 43 次/次 —— **功过确实就在那两块上**。
（探针是单线程、直接调 brotli 的，它的 µs 不是库的 µs，别与下面的表混用。）

自建服务上同一件事的**因果**见证（同一份入口二进制、`/json/50?m=6`、只改进程环境）：

| 配置 | minor fault/请求 | CPU µs/请求 |
|---|---:|---:|
| `br`，默认 | 72.06 | 513.5 |
| `br`，只抬 `MALLOC_MMAP_THRESHOLD_` | **78.66** | 536.5 |
| `br`，两个阈值都抬 | **0.00** | **387.0** |
| `br`，默认（再一遍） | 72.02 | 522.0 |
| `gzip`，默认 | 0.00 | 271.5 |
| `gzip`，两个阈值都抬 | 0.00 | 273.0 |

两个环境变量谁都不碰 brotli 的算法，只改「这块内存还不还给内核」，而每请求 CPU 跟着掉了
约 25 %。只抬 mmap 阈值**反而更糟**（72.06 → 78.66）：那两块改从主堆发，`free` 时
`malloc_trim` 去收缩 brk、页还是还回去了，且按页粒度还 —— 要让缺页归零，**两个都得抬**。
`gzip` 那两行是负对照：它走 `deflate_slot`，一个字节都不动。

#### 修法：线程本地 bump 竞技场

`BrotliEncoderCreateInstance()` 收 `alloc_func` / `free_func` / `opaque` 三件套，那正好是
放进「线程本地、一次要一块、跨请求携带」的地方 —— 复用的是**内存**，不是状态。

`src/web/uvcpp_http_compress.cpp` 新增 `brotli_arena`：每线程一块、上界 1 MiB
（`kBrArenaCap`），`compress()` 进 brotli 那一支时把游标拨回 0、把竞技场交给编码器。
竞技场**只发不收**：一次压缩里 brotli 要的块都在它自己的生命期内还回来，而
`DestroyInstance()` 返回后一块都不剩（这是它的契约），所以整段用完拨个游标就够，不要空闲链、
不要每块的头部。装不下就回落 `std::malloc`（大正文的块会超过上界），并记下水位，**下一个
请求**按水位长大；本机那条工作点第一请求走回落、之后收敛到约 730 KiB 再也不长。三种情形
（全在竞技场里 / 全回落 / 混着）由 `free` 那边一句地址区间判断分开，**产出与内存从哪来无关**
（这是 `compress()` 本来就有的判据，见 §4.16）。

#### 判据一：同一份入口二进制，只换 `.so`

`/json/50?m=6`、64 条 h1 连接、每格 30 000 个请求、服务端 `taskset -c 8-15`、压测端
`-c 0-7`，A B B A ×3 轮（每格一个新进程），逐格读 `/proc/<pid>/stat`：

| 库 | `Accept-Encoding` | minor fault/请求 | CPU µs/请求 | 线上字节/请求 | VmRSS |
|---|---|---:|---:|---:|---:|
| 改前 | `br` | 72.165 | 515.5 | 1 393.0 | 22.7 MiB |
| 改后 | `br` | **0.001** | **398.5**（−22.7 %） | 1 393.0 | 25.8 MiB |
| 改前 | `gzip` | 0.001 | 270.7 | 1 567.0 | 22.3 MiB |
| 改后 | `gzip` | 0.001 | 272.8（+0.8 %，**负对照**） | 1 567.0 | 22.2 MiB |

缺页那一列是确定性的（跨 4 个数量级）；`gzip` 那一行**必须**不动 —— 竞技场只挂在 brotli
那一支上，它也确实不动。**同一形状重跑了一遍**（改完注释后重编的最终产物）：
`br` 72.620 → 0.001 次缺页、522.3 → **393.3 µs（−24.7 %）** —— 两次读数把这一刀的量级
夹在 −22.7 % ~ −24.7 % 之间，缺页那一列两次都是 0.001。产出：两个臂的压缩字节 **md5 相同**
（`4cc22b71e879e528480ef4cce9ea6255`），解出来是同一份 8 397 B 的 JSON。
`VmRSS` 那一列是这一刀**唯一**的代价（8 个 worker 线程 ⇒ 约 0.39 MiB/线程），买的正是
「那些页别回内核」—— 改前那些页也是同一批页，只是每请求被还回去一次。

#### 判据二（微基准）：`br` 相对 `gzip` 的倍率从 3.25 掉到 1.78

§4.16 读数二那把尺子（同一进程内交替压同一份 8 397 B、`-O2`、`taskset -c 2`）：

| 库 | `gzip` L6 | `br` q5 | `br`/`gzip` | `br` 缺页/次 |
|---|---:|---:|---:|---:|
| 改前 | 43.56 µs | 141.68 µs | 3.252 | 220.244 |
| 改后 | 49.77 µs | **88.57 µs** | **1.780** | **0.000** |

`gzip` 那一列两次读数差 6 µs 是**两次进程之间的漂移**：这条路上一个字节都没改，所以只读
**同一次读数内部**的比值 —— 3.252 → 1.780，`br` 相对 `gzip` 的超额代价掉了约 45 %。

#### 这一刀**没有**关掉的那件事（如实记）

竞技场把 `br` 拉近了 `gzip`，但**没有**让它越过 `gzip`。按平台自己的口径
（`scripts/gen_leaderboard_data.py:_eff_fn`，`eff = rps × (min_bpr / bpr)²`），`br` 相对
`gzip` 的 `eff` 是：

- 改前 **0.664**（`br` 倒扣 33.6 %）
- 改后 **0.866**（仍然倒扣 13.4 %）

⇒ **对 `json-comp` 这一档，「开着 brotli」依然是净亏的**，这一刀只把亏的幅度收回约三分之二。
这与 §4.16 的结论一致、而不是推翻它：`br` 值不值取决于条目有没有把响应体的指纹写进
`cache_tag`（写进去就是纯赚：变体缓存命中时 8.55 对 8.85 µs、字节还少 9.9 %），而
`json-comp` 那三条今天**没填** —— 填它是「把算好的应答预先备好」，按本仓的规矩不做。
所以这一刀的位置是：**把 `br` 这个能力的代价压下来**，不是「修好 `json-comp`」。

#### 复现

```bash
# 判据一：同一份入口二进制，只换 .so（两个臂各一个目录，LD_LIBRARY_PATH 指过去）
#   LD_LIBRARY_PATH=<arm> h2load -p http/1.1 -m 1 -c 64 -t 8 -n 30000 \
#     -H 'Accept-Encoding: br' http://localhost:8080/json/50?m=6
#   逐格读 /proc/<pid>/stat 的第 10 字段与 $14+$15；VmRSS 读 /proc/<pid>/status
# 因果那一表：同一份二进制，环境里加
#   MALLOC_MMAP_THRESHOLD_=134217728 MALLOC_TRIM_THRESHOLD_=1073741824
# 判据二：仓外微基准（不随仓库发布）
#   g++ -std=c++11 -O2 -o mb mb.cpp -luvcpp && taskset -c 2 ./mb <8397 B 的 JSON> 4000
```

这一节没有 `LD_PRELOAD` 计数器、没有 ptrace、没有 perf：全部数字来自 `/proc/<pid>/stat`、
`/proc/<pid>/status` 与一个仓外微基准。


---

### 4.18 静态腿剩下的那把全局锁：`LOOP_STAT` 档改成**每条循环自己的前台副本**（**第十三套装置**，`LD_PRELOAD` 按调用点计费的锁计时器）

#### 先修量具：这一档卡的是并行度，不是每请求成本

平台第六轮那批读数里，**走静态处理器的档全都封在 25~31 核**，而同机同轮的
`json-tls-4096` 用掉 **63.73 核**（它的每请求成本比静态那几档**更高**）。平台给每一档的
cpuset 是同一个（`scripts/lib/profiles.sh`，`0-31,64-95`），静态腿的头名们用 59~65 核 ⇒
差的那一项是**静态处理器**，不是 CPU 预算。所以这一刀量的是"静态处理器的热路上还剩多少
**跨循环共享**"，判据不能取 rps。

装置：`LD_PRELOAD` 拦 `pthread_mutex_lock` / `pthread_mutex_unlock`，用
`__builtin_return_address(0)` 把每一次取锁归到**调用点**，累计 `n` / 持有时长 / 等待时长，
再由 `SIGUSR1` 打一张快照。形状照平台 `static-h2`：`h2load -m 32 -c 256 -t 8 -D 6s`、
9 条循环、服务端 `taskset -c 9-17`、压测端 `0-8`，语料是 §4.13 那份 **ext4** 上的 50 文件
副本（fuseblk 那份单文件 `stat` 是 336 µs，会把锁的账整个埋掉）。

改前（同一份入口二进制，只换 `libuvcpp.so`，两轮）：`mutex_lock` **2.03 / 2.04 次每请求**，
其中 `collect_hints()` 那一处**持有 2021~2631 ns、后面还跟着 7.1~9.6 µs 的等锁**，
`lookup_cache()` 那一处持有 468~597 ns、等 5.9~9.2 µs。按"那把锁的吞吐上限就是 1/持有"
算，**0.30~0.46 M rps** —— 而这一档的读数本来就在二十几万 rps 上。

**空临界区对照**（把临界区里的活整段删掉、只留取锁）：1534 ns 的持有里**还有 905 ns**。
⇒ 贵的是**争用本身**，不是临界区里干的活 ⇒ 这一刀只能是"**去掉取锁**"，
把临界区改短没有意义。换容器也一样：把 `std::map` 换成 `unordered_map` 是个 wash（同一次
读数内两臂互相盖住），所以也没有走"更快的数据结构"那条路。

#### 机制：`LOOP_STAT` 档的读写本来就在同一条线程上

`probe_job()` 在 `LOOP_STAT` 档里是从 `serve()` 调的（`probed_on_loop = true`）——
也就是说**读这份记忆的那条线程就是写它的那条线程**。于是"每条循环一份前台副本"在这个档里
**一把锁都不用取**，而 `POOL` 档的写发生在 worker 上，所以这两张表**只在 `probed_on_loop`
为真的路径上被碰**，`POOL` 档一个字节都不动。

- **记忆（memo）副本**：`hints_` 那份记忆本来就是个**纯记忆** —— 每次用到都要重新
  `stat` 指纹校验（`src/webapp/uvcpp_web_static.cpp:1406-1406` 那一支，见 §4.13），
  校验不过就落回完整解析。所以按循环存一份在语义上是安全的。作废靠**一个整数**
  `front_gen_`（`src/webapp/uvcpp_web_static.cpp:997-997`）：`clear_cache()` 里 `+1`
  （`src/webapp/uvcpp_web_static.cpp:1735-1735`），保住"清缓存之后第一次请求必定走完整
  解析"这条**既有的**性质 —— 逐循环那两张表没有锁，走不动它们，所以只能这样作废。
- **字节副本**：存的是**弱引用**（`src/webapp/uvcpp_web_static.cpp:1140-1140`）。
  它按不住字节 ⇒ `bytes` 的账仍然精确，而且既然按不住，全局表把一份淘汰掉时前台**自动**
  失效（`lock()` 拿到空 ⇒ 擦掉这一条 ⇒ 落回全局表）。`clear_cache()` 对这一半是**免费**的。
- 两张表都挂在既有的**按循环分桶**上（`src/webapp/uvcpp_web_static.cpp:1124-1124` 与
  `src/webapp/uvcpp_web_static.cpp:1140-1140`，就是 `drain_retired()` 用的那个
  `map<uvcpp_loop*, retire_bucket>`，节点从不 `erase` ⇒ 地址稳定），所以前台查找是
  "一次线程本地缓存命中 + 一次 `std::map` 查找"，零取锁。

#### 判据一：确定性 —— 每请求取锁次数与持有时长（A B B A 交错）

| 臂 | `mutex_lock`/req | 持有/req | 等待/req | 2xx rps |
|---|---:|---:|---:|---:|
| 改前 | 2.03 / 2.04 | 3679 / 4171 ns | 7761 / 9368 ns | 119 045 / 100 949 |
| 改后 | **0.03 / 0.02** | **969 / 1259 ns** | **183 / 239 ns** | 142 933 / 120 283 |

改后剩下的那 0.02~0.03 次是前台副本的**首次登记**（每条循环每个键一次）与表满清空后的
重填，`collect_hints()` 那一处在改后的调用点表里**整个消失**，`lookup_cache()` 那一处从
每请求一次降到 **0.0041 次**（只有前台没命中时才落回全局表）。

#### 判据二（仓内、确定性）：两条循环各自的前台副本

`tests/functional/web_app_multiloop_func.cpp` 新增 `test_static_cache_two_loops_loopstat()`：
`set_loops(3)`（2 条 worker 循环，连接 `i` 落在 `1 + i % 2` 上）、`revalidate = LOOP_STAT`，
12 个请求必须 `ok == 12`、`cache_entries() == 1`、`cache_misses() == 1`、`cache_hits() == 11`；
改文件内容（长度也变）之后那 4 个请求必须全部读到**新内容**、`cache_misses() == 2`；
再两轮"`clear_cache()` 之后只发一个请求"必须各自 `misses` 恰好 `+1`、`hits` 不动。
`tests/functional/web_app_static_func.cpp` 的 `fs_count` 子用例里加了
`measure_memo_reset()`：`clear_cache()` 之后**第一个**请求必须 `realpath` `+1`（走完整解析）、
紧接着那一次必须 `+0`（走记忆）。

**变异（如实记）**：只把 `front_gen_.fetch_add(1)` 那行删掉，上面两条**都不会变红** ——
因为字节副本那一半的失效是**弱引用免费给的**，生成号只被记忆那一半看得见，而记忆的失效能
被"多一次 `realpath`"抓到、抓不到的是"内容对不对"。把"弱引用"改成"再拿一份强引用"
**并同时**删掉生成号那一行之后：**3 条红**。也就是说这条判据**同时**见证了两个失效机制，
少一个都不红 —— 这正是"两个机制各自负责哪一半"必须是量出来的、而不是想出来的原因。

#### µs：本机分辨不了（如实记）

两轮交错 rps 是 119 045 → 142 933（+20.0%）与 100 949 → 120 283（+19.2%），中位数
109 997 → 131 608（**+19.6%**）。但那是 9 核上的读数、且**压测端自己也顶着**，所以这一栏
只当"方向一致"的旁证。**平台的效应只能按"1/持有"那个模型预测**，本机不作验收。
（这一刀**还没有进过任何一轮平台读数**，第六轮的 pin 是 `02ae418`，早于它。）

#### 这一刀之后剩下的那一个点（未探，如实记）

改后 913 ms 的持有总时长里**有 908 ms 落在同一个调用点**：`uv_mutex_lock`（libuv 自己的
互斥量包装，`uv_mutex_lock` 里 `call pthread_mutex_lock@plt`），占请求的 **1.09%**、
**每次持有 ~115 µs**、最长等待 3.5 ms。本仓 `src/` 里**没有**任何 `uv_mutex_*` 调用
（`grep -rn 'uv_mutex_' src/` 为空）⇒ 它是 libuv 内部的锁，不在本次动的那张表上，
也不是这次改动造成的（改前改后的计数完全一样：7908 / 7899 次）。按
`1.09% × 115 µs = 1.25 µs/req` 的串行化折算，它的上限还在本次读数之上。
**未探。**

#### 复现

```bash
# 装置（仓外，不随仓库发布）：LD_PRELOAD 的锁计时器 + 一个跑 static-h2 形状的 rig
#   服务端：taskset -c 9-17  压测端：taskset -c 0-8
#   h2load -m 32 -i <20 个 URL 的表> -H 'Accept-Encoding: br;q=1, gzip;q=0.8' \
#          -c 256 -t 8 -D 6s https://localhost:8443
#   两个臂各一个目录（只换 libuvcpp.so 的 LD_LIBRARY_PATH），A B B A
# 仓内判据：ctest -R 'web_app_multiloop_func|web_app_static_func'
```

**一处必须写下来的前提**：语料要在 **ext4** 上（`/tmp`），不能在仓所在的 fuseblk
(`ntfs-3g`) 挂载上 —— 同一个小文件 `os.stat` 是 **336.92 µs 对 1.75 µs**，不换的话整个
静态腿的读数（4 280 rps 这个量级）连比例都不能拿去预测。


### 4.19 WebSocket 回声那条路上被漏掉的一族小分配：`uvcpp_buf` 自由表的链表原本放在块里（**第十四套装置**，`LD_PRELOAD` 逐 (调用点, 尺寸) 计费的分配计数器）

#### 为什么量这条腿

`echo-ws-pipeline-4096` 是计分档，第七轮是 **29 440 675 rps / 2.31 µs 每消息**（`CPU/req`，
那一轮 −6.8% 是单档最大的回退）；而这一档的报文就是 **`"hello"`（5 字节）**的文本帧、
服务端原样回显 ⇒ 这条腿上**没有一个字节的账可以按字节摊掉**，量出来的每一笔都是
**每消息的固定开销**（分帧解析一次、回声写出一次）。同族的 `echo-ws-4096` 是 22.60 µs/消息、
`-512` 23.63、`-16384` 25.74（同一轮），三条的差别在**一个读事件里有几帧** —— `pipeline`
那三档一个事件里有多帧（本机用 `PIPE=16` 对齐这个形状）。

装置（仓外，`/tmp/wsrig/`）：压测端是一个零依赖的原始套接字客户端（形状照
`scripts/validate-ws.py`，握手之后跑紧凑回声循环），第 7 个参数就是"一次 `sendall` 发几帧"；
服务端是**同一份入口二进制**（`/tmp/wsrig/entry_src`），**两个臂只换 `libuvcpp.so`**
（`build-docker` 那份 `Release`、`UVCPP_ENABLE_MEMORY_POOL=0`，各拷一份进自己的目录），
A B B A 交错。分配计数器沿用 §4.10／§4.17 那一族的 `LD_PRELOAD` 版本，但这次**按
(调用点, 尺寸) 分桶**、尺寸只记 ≤512 的（64 KiB 那条读缓冲由 `alloc_buf` 单独一行看）。

#### 根因：自由表的链表放在块里，于是 1~7 字节的块一块也留不住

`uvcpp_malloc_block_cache`（`src/uvcpp/uvcpp_alloc.h`）在 `1.3.29` 落地时，自由表用的是与
M6 那张 `uvcpp_block_cache` **同一套形状**：把"下一块"写进**块自己的头 8 字节**。这一族
服务的块却**不保证有 8 字节** —— 要把链表指针写进块，就要求 `size >= sizeof(void*)`，
于是 `put()` 对 1~7 字节的块只能原地 `std::free`，`try_take()` 也就永远命不中。
`resize_impl()` 那两条"新造一块"的分支交出来的尺寸正好全在那一侧：改前 `resize_impl`
那个 `malloc` 调用点**稳定 4.00 次/消息、平均 5.5 字节**（3 块 5 字节 + 1 块 7 字节），
对应的 `std::free` 是 3.00 次/消息（落在改前 `free_own()` 的裸 `uvcpp_free` 上）。
**这四块一次都没进过表。**

#### 修法一（本刀）：自由表搬到表里

每个槽改成一张 `void* head[kSlotMax]` 数组，链表指针存在**表**里而不是块的头 8 字节上。
`put()`/`try_take()` 从此对块的大小**再无任何假设**，也不再**写**取到的块（改前那 8 字节是
被链表指针覆盖掉的，接手方拿到的内容同样不保证）。同时补了一条必要的规则：**已经排空的槽
可以改服务新尺寸** —— 改前 `count` 掉到 0 的槽永远不会再被分配，长期运行的线程一换工作
形状，这张表就等于只剩头几个尺寸。上界不变：每槽 64 块 × 单块 ≤4 KiB × 4 槽
= **每线程最多留 1 MiB 的块**，表自身 ≈2 KiB。

#### 修法二：还块那一侧还漏了一个入口

只做表外置，读数从 11.255 走到 **8.255**（−3.000，与"3 块 5 字节"逐字对上）而不是 −4.000。
查出来的原因：剩下那一块 7 字节的**根本没还给这张表** —— 它走的是 `uvcpp_buf::free_buf()`
里的裸 `uvcpp_free`。于是补了两处：

- **值形态交接**：`uvcpp_tcp_client::write(const char*, size_t, cb)` 的两条分支从
  `out_uv_buf()` + `set_uv_buf(raw, true)` 换成 `release_uv_buf(&hb)` + `set_uv_buf_block(hb)`
  —— 块的所有权与形状都不变，少掉的只是那个 `uv_buf_t` 包装本身的一次分配（每写一次一笔，
  在 `PIPE=16` 上摊薄 16×），块则改从 `uvcpp_write` 的**值形态第 1 块**那条路还回来。
- **只留一处知道"还块该还给谁"**：`src/req/uvcpp_write.cpp` 新增 `release_own_block()`
  （池那档原样 `uvcpp_free`，其余还给本线程的表），**四个**自有块的释放点全部走它 ——
  `~uvcpp_write` 的第 1 块、`release_second()`、`set_uv_buf()`、`set_uv_buf_block()`。
  每一处都拿**能看见的长度**（`len`，由 `uvcpp_buf` 的不变式恒 ≤ 真实容量）做键 ⇒
  只会"少复用"，绝不会发出比要的小的块；对不上任何槽时当场 `std::free`，
  与改前的 `uvcpp_free` 逐字同义。

#### 判据一（确定性，A B B A 交错，同一份入口二进制只换 `.so`）

| 形状 | 臂 | `malloc`/消息 | `free`/消息 |
|---|---|---:|---:|
| `PIPE=1`，100 000 消息（分母含 5 000 热身） | 改前 / 只做表外置 / 三处全改 | 11.255 / 8.255 / **6.255** | 11.163 / 8.163 / **6.163** |
| `PIPE=16`，200 000 消息（分母含 5 000 热身） | 改前 / 三处全改 | 3.692 / **0.567** | 3.645 / **0.520** |

两臂**组内零散布**（同一份二进制重复跑逐位相同）。`PIPE=16` 那一行是这一档的关键：
一个事件里 16 帧之后，每消息那 **3.00 块 5 字节整个消失**，剩下的 0.567 全是**每写一次**
那笔固定成本（200 / 192 / 32 / 24 / 24 字节那五笔 `new`，见 §4.10 那张表）—— 它在
`PIPE=16` 上被摊薄 16×。**所以"每消息分配数"这一个指标在两条形状上会给出 5.00 与 3.13
两个不同的答案，引用时要说清是哪一条。** 三个臂的 `libuvcpp.so` md5：
`e453e8b1…`（改前）→ `53b6b408…`（只做表外置）→ `f4ca6ca1…`（三处全改）。

#### 判据二（端到端，不挂计数器）：`/proc/<pid>/stat` 括 CPU

分配计数器自身会给每一次 `malloc`/`free` 加一笔（哈希 + 自旋锁），**挂了计数器的 µs 是被
抬高的**、而且块越多抬得越多 ⇒ 它只配用来读**计数**。端到端那一栏因此**不挂**
`LD_PRELOAD`，只用 `/proc/<pid>/stat` 的 `utime+stime` 括窗口（服务端 `taskset -c 0-8`、
压测端 `9-17`，2 000 000 消息、`PIPE=16`、一轮一对）：**0.775 → 0.730 µs/消息（−5.8%）**，
**255 891 → 267 986 msg/s**。

计数器那笔税是可以对账的：`PIPE=16` 挂表时是 0.837 / 0.856（改前）对 0.786 / 0.740
（改后），不挂表时是 0.775 对 0.730 —— 差的那 ~0.05 µs 正好对上改前多出来的
**7.34 次 (分配+释放) × ~7 ns**。**如实记两条**：① 这条腿在本机是**系统调用占优**的
（`PIPE=1` 那一格量出来 sys 5.7~6.1 µs 对 user 1.8~2.1 µs），所以本机的绝对 µs 不许拿去
预测平台那一格；② `PIPE=1` 那一格 µs 上**根本分辨不出来**（挂表 7.665 / 7.993 / 8.004
对 7.863 / 8.082 / 7.728 / 7.525 / 7.563，四组互相盖住）—— 11.3 次分配的那点税只有约
0.08 µs，压在 7.7 µs 的总量上就是 1%。**验收走上面那两张计数表，µs 只当"方向一致"。**

#### 没做的那一件事（如实记）

`uvcpp_ws_connection::pump_send()` 还能改成 `write_owned` 那条**复用**形状，省掉队列里
"取出 → 重设 → 归还"那一趟：在 `PIPE=16` 上值**约 0.3125 次分配 + 0.3125 次释放每消息**，
按上面那条 ~7 ns/次 的兑换率折 **≈0.9% 的 µs** —— 不到这一刀的五分之一（这一刀在
`PIPE=16` 上是 3.125 次分配+释放）。要动的是 ws 的发送队列本身，**不做**。

#### 复现

```bash
# 装置（仓外）：/tmp/wsrig/{meas.sh,wsdrive.py} + 同一份入口二进制 /tmp/wsrig/entry_src
NOTRACE=1 N=2000000 PIPE=16 LIBDIR=<臂目录> /tmp/wsrig/meas.sh 2000000 1 n16post
#   臂目录里只放一个 libuvcpp.so；服务端 taskset -c 0-8、压测端 9-17，A B B A 交错
# 仓内判据：ctest -R 'ws'（test_web_ws_* 八条 + test_web_app_ws_* 两条，
#           build-brotli 与 build-all 两棵树上各跑一遍）
```

**一处必须写下来的前提**：两个臂只能是**同一份入口二进制**换 `.so`。`uvcpp_http_server`
这类内部布局一改，入口那份二进制就与库对不上（§4.17 记过一次：差 80 字节就把相邻 h1 的
vptr 抹掉、闲置扫描首拍段错误）—— 换 `.so` 之前先确认跑的是刚编出来的那一份。


### 4.20 h1/h2 每条读事件那一次 64 KiB 分配：`alloc_cb` 的缓冲改从**每线程两张尺寸槽**里发（**第十五套装置**，callgrind 指令数 + `LD_PRELOAD` 分配直方图 + 交替 A/B）

#### 为什么量这条腿

`json` 那一族（`json-h2c-1024` 在第六轮掉到 656 607 rps）当时记的是"DOM 的合规代价、
不许回退"（memory `json-dom-path-cost`）。**那个结论只说了"不许改 DOM"，没说底下没有别的账。**
同一条路上还有一个和 DOM 完全无关的固定成本，量出来是**每条读事件一次 64 KiB 的
`malloc`+`free`**：`internal_alloc_cb` 拿 libuv 给的 `suggested_size`（TCP 流恒为
**65536**，`_local_deps/libuv/src/unix/stream.c`），交给 `uvcpp_buf::alloc_buf()` →
匿名命名空间的 `alloc_raw()`（裸 `std::malloc`），read_cb 一返回就 `uvcpp_free_bytes`。
`pipeline = 1` 时**一个读事件就是一个请求** ⇒ **每请求一次 64 KiB 分配 + 一次释放**。

单看这一对分配不值钱。贵的是它对**分配器**做的事：64 KiB 落在 large bin 一侧，一次
`free` 会把相邻的可合并块并回去、再按 `FASTBIN_CONSOLIDATION_THRESHOLD` 触发一次
fastbin 合并扫描 —— 与这条路上真正的大头（nlohmann 的 DOM、行物化、WS 回声那些
**每应答 ~10²~10³ 次**的小分配）正面撞上。**所以这条腿的收益与"每应答分配多少次"成正比、
与"每事件分配多大"无关** —— 这也是为什么它在 h1 `baseline11` 上几乎白搭、在 `json` 上很值钱。

#### 确定性判据一：callgrind 指令数（同一份入口、同一个 URL，`-c 4 -n 20000`）

| URL | 改前 | 改后 | 差 |
|---|---:|---:|---:|
| `/baseline11?a=1&b=2` | 501 010 150 ／ 500 931 657（两次独立） | **494 196 681** | **−1.36%** |
| `/json/50?m=6`（应答 8 397 B） | 4 550 109 494 | **3 796 143 977** | **−16.57%** |
| `/json/1?m=3`（应答 203 B，对照） | 309 083 522 | 挂 shim 版 326 208 715 | **+5.5%**（纯 shim 开销） |

`/json/50?m=6` 那条的归因（自耗，`callgrind_annotate`）：

| 符号 | 改前 | 改后 |
|---|---:|---:|
| `malloc.c:_int_malloc` | 546 559 686（12.01%） | 184 573 294（4.86%） |
| `malloc.c:malloc_consolidate` | 214 831 713（4.72%） | **929 527（0.02%）** |
| `malloc.c:unlink_chunk.isra.0` | 83 495 443（1.84%） | **916 593（0.02%）** |
| `malloc.c:_int_free` | 330 250 196 | 330 035 400（不动） |

`baseline11` 那条的指纹是 `_int_malloc` **4 710 713 → 1 750 865**（每应答只分配十来次的那条路，
省下的就是读缓冲这一对）；它的 `malloc_consolidate` 本来就只有 85 465，**所以 h1 baseline
这条路上这一刀没有可吃的**。

#### 确定性判据二（零源码改动的预测臂）：`LD_PRELOAD` 那个 shim 先量一遍

按本仓纪律（先量再改），源码版动手之前先用一个 ≤50 行的 `LD_PRELOAD` shim
（`/tmp/latrig/shim/readpool.c`：拦 `malloc`/`free`，尺寸正好 64 KiB 时走线程本地自由表）
把同一件事**在不改源码的情况下**量出来：`/json/50?m=6` 4 550 109 494 → **4 062 528 230**，
其中 shim 自己的 `malloc` + `free` 是 36 318 909 + 92 542 198 = **128.86M（3.2%）**
⇒ 毛效应 ≈ **−13%**。**源码版（−16.57%）比 shim 版还低那 3.2%** —— 因为 shim 每次都要
过一遍自己的哈希/自旋锁，而源码版在 `alloc_cb` 里直接命中，一次函数调用都不多。

#### 判据三（端到端，`/proc/<pid>/stat` 括 CPU；同一份入口二进制只换 `.so`，A B B A）

| 形状 | 改前 µs/req | 改后 µs/req |
|---|---:|---:|
| `/json/50?m=6`，`-c 256 -n 300000`（srv `0-8`、drv `9-17`） | 139.400 ／ 155.233 | **122.567 ／ 130.500** |
| `/baseline11`，**照 `latency-500k-8cpu` 的形状**（srv `0-7` = 4 个物理核 + 它们的 SMT 兄弟、drv `8-17`），`-c 1024 -t 8 -n 2000000` | 11.375 ／ 11.430 | 11.455 ／ 11.735 |

第一条：**两臂不重叠**，中位 **147.3 → 126.5 µs（−14.1%）**；rps 44 910~50 934 → 56 285~59 172。
第二条是这份读数的**负结果，如实记**：中位 11.40 → 11.60（**+1.7%，落在散布内**），
而且同一条腿在 `srv 0-8 / -n 3000000` 那组里散布大到两臂互相盖住 ⇒
**这一刀在 h1 `baseline11` 上判"中性"**，只作"没有反向"的旁证。
（`latency-500k-8cpu` 压的就是 `GET /baseline11?a=1&b=2`，所以这一格对那一档直接可读。）

#### 修法：每线程两张**精确尺寸**的槽，指针存在表里

`src/net/uvcpp_tcp_client.cpp` 顶部新增匿名命名空间的 `class read_block_cache`
（2 槽 × 每槽 2 块，`4096 ≤ size ≤ 256 KiB`）+ 两个内联包装 `alloc_read_buf` / `free_read_buf`，
9 处 `uvcpp_free_bytes(buf->base)` 与 1 处 alloc 各改一行。三条设计取舍：

- **按精确尺寸取，不按尺寸类。** 实测这条路上真的只出现两个尺寸（4 KiB 兜底与 64 KiB），
  精确匹配就零猜测；尺寸类要引入舍入规则，而"发一块比要的小的"是这个库绝不能出的错。
- **指针存在表里，不写在块的头 8 字节上。** §4.19 刚为同一件事吃过一次亏
  （`uvcpp_malloc_block_cache` 把链表指针写进块，于是 1~7 字节的块一块也留不住）——
  这里从第一天就不写块。
- **与 `uvcpp_malloc_block_cache` 分开两张表。** 那张的上界是 4 KiB × 4 槽 × 64 块
  = 1 MiB；这张只服务读缓冲这一种尺寸，混进去会让它的 4 KiB 上限变成噪音。
- **只在 `UVCPP_ENABLE_MEMORY_POOL=0` 编译进来**（Dockerfile 那一档就是 0），池那档原样
  走 `uvcpp_buf` 的既有路径。每线程最多留 2 × 64 KiB + 2 × 4 KiB = **136 KiB**，表自身 ~2 KiB。

#### 证伪：杠杆不是"缓冲的大小"，也不是 `FASTBIN_CONSOLIDATION_THRESHOLD`

中途试过把读缓冲**封顶到 16 KiB**（就压在 glibc 那个 65536 的阈值之下）：它**确定性地生效了**
（`LD_PRELOAD` 分配计数器看每请求字节数 **65 920 → 16 796**），而 **callgrind 指令数一格没动**、
`malloc_consolidate` 也照旧。⇒ 贵的不是"块有多大"，是**每请求那一次 large-bin 分配/释放
本身**把 `unlink_chunk` 与 fastbin 合并扫描拖进了热路。封顶这条路已经原地撤销，不再考虑。

#### 交互与边界

- 改前那份 `.so` 的 md5 是 `f4ca6ca1…`，**就是 §4.19 的第三臂** ⇒ 这两刀是**叠着**的，
  本节的"改前"包含 §4.19 的全部改动。
- 改后 `0ac7c83a…`。两个臂只能是**同一份入口二进制**换 `.so`（理由同 §4.17/§4.19）。
- 这只对**分配密集**的腿有意义（json 那一族、async-db 的行物化、WS 回声）；对
  `baseline`/`latency-500k` 这类每应答十来次分配的腿**中性**。

#### 复现

```bash
# 装置（仓外）：/tmp/latrig/{ab.sh,cg.sh,pool.sh} + 同一份入口二进制 /tmp/latrig/entry
#   两个臂：/tmp/latrig/before/libuvcpp.so = f4ca6ca1…、/tmp/latrig/after/libuvcpp.so = 0ac7c83a…
ARM=/tmp/latrig/before /tmp/latrig/ab.sh 0-7 8-17 lb1 'http://127.0.0.1:8080/baseline11?a=1&b=2' -c 1024 -t 8 -n 2000000
ARM=/tmp/latrig/after  /tmp/latrig/ab.sh 0-7 8-17 la1 'http://127.0.0.1:8080/baseline11?a=1&b=2' -c 1024 -t 8 -n 2000000
# callgrind（SHIM 空 = 不带 shim）：SHIM= /tmp/latrig/cg.sh 20000 cgj6 'http://127.0.0.1:8080/json/50?m=6'
# 零源码改动的预测臂：SHIM=/tmp/latrig/shim/readpool.so /tmp/latrig/cg.sh 20000 cgj2 'http://127.0.0.1:8080/json/50?m=6'
# 仓内判据：ctest -R 'tcp|web|ws|h2'（build-brotli，池关；22/22 绿）
```


### 4.21 `async-db` 那条应答的 DOM 改流式构造器：**量过、判为不合规、没有采纳**（**第十六套装置**，逐字节比对 + `LD_PRELOAD` 分配计数器 + 合规判读）

#### 结论先说：这一档要的是"proper json parser"，所以改回 DOM

维护者 2026-10-15T14:48:01Z 在 PR #1568 上给的原文只有一句：

> You need to use a proper json parser (for example nlohmann/json) for tests that do
> json serialization, unless you classify as an engine.

当时那一轮的树（`9257623`）把 `json-*` 与 `/async-db`**一起**换到了 `uvcpp_json_writer`
上。判断这条指令射程的那份证据不在 `json-*` 的档里，而在这一档自己的档里 ——
`h1/async-database/implementation.md:38` 把它列进了"这一档在量什么"：

> - **Result parsing + JSON serialization** - converting Postgres rows to structured JSON
>   with nested objects

⇒ `/async-db` 就是"a test that does json serialization"，而 `uvcpp_json_writer` 是
`tuned.md` 列在 tuned 一栏的 "Alternative JSON serializers"；本入口 `meta.json` 写着
`"type": "emerging"`、`"mode": "standard"`，两个都不是 `engine` ⇒ 豁免条件不成立。
**换成流式构造器，正好把这一档声明它要量的那件事拿掉**，省下来的客户端 CPU 是拿合规换的。

还有一件更直接的：**入口自己的 `meta.json` 里已经把这件事写下过**——
`"description": "… JSON serialized per request through the framework's uvcpp_json DOM
(nlohmann/json, **no pre-rendered bytes**) …"`。真换上去，那段描述就成了假的。

这一档的 `standard` 栏确实一个字没提 JSON 库（只有「async PostgreSQL driver with standard
connection pooling … Size the pool from `DATABASE_MAX_CONN`」），而 standard.md 又有那条
『If the framework itself bundles or officially recommends a specific library, that
library is acceptable』的例外 —— **这条推理链是通的，但它绕不过维护者那句直接的、写明
"json serialization"的话**。而且收益正好落在没有分的地方：这一档是 **Reference-only**，
对合成奖牌分贡献 0（`implementation.md` 顶部自己写着），改与不改只动它自己那一格
`cpu_per_req_us`。**为一个 0 分的格子去撞一条已经被告知过一次的规则，不合算。**

（`json-*` 那一族身上的规则更直接：`json-compressed` 的 standard 栏是「Must use the
framework standard JSON serialization … no bypassing the response pipeline」、`json-h2c`
是「no custom serializers」。**§4.20 把那一族记成"DOM 是合规代价、不许回退"，这一节是同
一条规则落在第二个档上的样子** —— 不是"这一档不一样"，是"这一档也一样"。）

#### 那这一档还剩什么合规的客户端 CPU 可做

判据二那一栏把账分得很干净：**774 次分配/应答里 694 次是 DOM，剩下 79.7 次是驱动侧的
行物化**（`src/db/uvcpp_db_pgsql.cpp` 的 `value_from_pg`，每个单元格两次分配）。
去掉 DOM 那 694 次不许做，**那就只剩驱动侧这 79.7 次是可动的那一半**，而且它是库里的、
与 JSON 无关的纯客户端开销。这一节把 DOM 那一半的账量清楚，价值就在这里：
它把"这一档还能改什么"从一句猜测变成了一个数（79.7 / 774 ≈ 10%）。

#### 量到的数（留档，免得重走）

改法（`build_async_db_json_stream()` + `write_jsonb_string_array()` 直写
`resp.json_str(std::move(body))`，列索引每应答解析一次、`tags` 那一列按 JSONB 文本原样透传）
与下面三栏读数都留着；**入口那一版已经 `git checkout` 回去了，树是干净的**。

**逐字节比对（5 个应答，含 50 行那个）** —— 键序刻意保持 DOM 那一套（`count` 在前、每项按
`std::map` 的迭代序），尽管平台的校验器是 `json.load()` 解析后再判结构
（`scripts/validate.sh:2195-2214`：只查 `count` 等于 limit、有 `rating.score`、`tags` 是
list、`active` 是 bool），理由是把"形状没变"变成**可判的**：

| 请求 | 字节数 | `cmp` |
|---|---:|---|
| `/async-db?min=10&max=50&limit=20` | 3 255 | 相同 |
| `/async-db?min=1&max=400&limit=50` | 8 007 | 相同 |
| `/async-db?min=9999&max=9999&limit=50` | 22 | 相同 |
| `/json/50?m=6`、`/json/1?m=3`（不走这条路的对照） | 8 397 / 203 | 相同 |

**`LD_PRELOAD` 分配计数器（`-c 64 -n 40000`，A B B A 四轮）**：

| | 分配/应答 | 字节/应答 | µs/请求（user / sys） |
|---|---:|---:|---:|
| 改前（DOM） | 773.793 ／ 773.821 | 63 732 ／ 63 736 | 269.250（240.25 / 29.00）／ 244.000（216.25 / 27.75） |
| 改后（流式） | **79.728 ／ 79.750** | **28 305 ／ 28 308** | **85.500（52.25 / 33.25）／ 87.250（53.25 / 34.00）** |

**每应答少 694 次分配（−89.7%）、少 35.4 KB**；两臂在分配这一栏上隔着一个数量级，
µs/应答也是隔开的（改后那两轮的最差 87.25 < 改前那两轮的最好 244.00）。**这 694 次就是
DOM 的价钱；剩下的 79.7 次才是驱动侧。**

**这一栏抓到了第一版的第二个错**：那一版把 `tags` 接成 `const std::string`（值）而不是
引用，读数因此停在 **95.753 ／ 95.769**、字节 28 815 ／ 28 818。改成引用后分配 −16.0 ／
−16.0 次、字节 −510 ／ −510（20 行里 16 行的 tags 溢出 SSO，4 行短到落在小串优化里），
µs/应答再 −8.0 ／ −8.0。**分配计数器在这里的作用不是"验收"，是"读代码时看不见的那一次拷贝"**
—— `operator[]` 与 `bytes()` 都返回引用，写成值就是白拷。

#### 顺带量到的一条 —— **这一条是采纳了的**（属 §4.20）：h2c 那条 json 腿上的读缓冲池

§4.20 的 h2 侧只给了"同一份代码路径"的推断，没有 h2 自己的读数。补上（`-p h2c`、
8082、`-c 64 -m 4 -n 400000`、srv `0-5` drv `6-17`，同一份入口二进制换 `.so`）：

| 臂 | µs/请求（两次） | user / sys |
|---|---:|---|
| `before`（无池） | 132.075 ／ 131.975 | 129.20 / 2.88、129.18 / 2.80 |
| `after`（有池） | **120.750 ／ 124.200** | 118.03 / 2.73、121.58 / 2.62 |

**−8.9%**，两臂不重叠。比 h1 `/json/50?m=6` 的 −14.1% 小一截，方向合理：h2c 一条连接上
压着 4 条流，**每请求的读事件数比 pipeline=1 的 h1 少**，可省的那部分也就少。

**另外两次跑法测不出东西，一并记下来免得重走**：按档的形状（`-c 1024 -m 32`）和
`-c 64 -m 4 -r 20000` 都不行 —— 前者压测端自己就是瓶颈（同臂内散布 ±25%，且**两臂的
先后顺序**能解释全部差值，反序再跑一次就翻转）；后者这台 h2load 的 `-r` 是**连接**速率，
`-r 20000 -c 64` 直接报 `the connection rate must be smaller than or equal to the number
of clients`。**这台机器的 h2c 腿只有在服务端确实是瓶颈时才有分辨率。**

#### 一个要记下的教训：那一次"逐字节相同"是恒真的

第一版把 `object_begin()` 忘了（根对象没开），于是 `member("count", …)` 在 `depth == 0`
上返回 `MISUSE`，函数**每一次都返回 false**、每一次都走进回落。此时逐字节比对**必然全绿**
—— 因为它比的正是"回落路对回落路"。是分配计数器（773.798 → 774.806，只多了 `reserve` 那
一笔 3 264 字节）先露的马脚，再往回落分支里塞一个 `fprintf` 才把它钉死（24 000/24 000 次）。
**"输出没变"只有在"新路真的走了"被独立证明之后才有意义** —— 这也是这一轮三个判据必须同时有的原因。

#### 备注：这条路上的 callgrind 不稳

`async-db` 的 DOM 臂在 callgrind 下以 `SIGBUS` 死在
`serializer<…>::dump → _M_append → __memcpy_avx_unaligned_erms`（"Non-existent physical
address at address 0x125957"），墙钟下同一条路跑几千万个请求没事。所以本节只用**分配计数**
与 `/proc` 的 `utime/stime` 作确定性判据，指令数不作为这一节的证据。

#### 复现

```bash
# 装置（仓外）：/tmp/latrig/{mke.sh,snap.sh,adb.sh,ab2.sh}
#   → 注意：入口的流式版**没有进仓**，下面这一臂是装置里的产物；
#     仓里（以及平台那一轮）跑的是 DOM 那一版。
#   入口两臂：仓库 HEAD 那份 main.cc（DOM，`git checkout` 后的状态）与装置里改过的
#   那一份，各自过 mke.sh 编成 /tmp/latrig/entry.{dom,stream}
#   （sha256 10f145d2… / aa02856a…，各 202 680 / 208 312 字节）
#   库两臂用的是**同一个** .so（入口侧改动）：build-docker/libuvcpp.so = 4a632c01…
cp -p .../HttpArena/frameworks/libuvcpp/main.cc /tmp/latrig/main.dom.cc
/tmp/latrig/mke.sh /tmp/latrig/main.dom.cc dom
# 流式那一臂的源：装置里那份改过的 main.cc（`mke.sh` 会先替掉 4 个路径常量再编）；
# 这里直接喂它那次 sed 的产物（`main.stream.rig.cc`，208 312 字节的入口就是它编出来的）
/tmp/latrig/mke.sh /tmp/latrig/main.stream.rig.cc stream
/tmp/latrig/adb.sh dom    0-7 8-17 adbr_dom 64 40000
/tmp/latrig/adb.sh stream 0-7 8-17 adbr_stream 64 40000
# 逐字节比对（snap.sh 从 $RIG/entry 起服务，两个臂各跑一遍、5 个 body 逐一 cmp）：
cp -p /tmp/latrig/entry.dom /tmp/latrig/entry && /tmp/latrig/snap.sh /tmp/latrig/snap3_dom/
cp -p /tmp/latrig/entry.stream /tmp/latrig/entry && /tmp/latrig/snap.sh /tmp/latrig/snap3_stream/
# h2c 腿（换 .so，入口同一份；这一条量的是库里的读缓冲池，与上面无关）：
ENTRY=/tmp/latrig/entry.stream ARM=/tmp/latrig/before /tmp/latrig/ab2.sh 0-5 6-17 h2b 'http://127.0.0.1:8082/json/50?m=6' -c 64 -m 4 -n 400000
```


### 4.22 h1 动态热路上的三处白拷：路由查找不再拷 `path`、状态行/响应头一次 `resize` 直写、查询串整串只扫一遍（**第十七套装置**，callgrind 指令数 + 逐字节比对）

#### 结论先说：−11.03% 的用户态指令，但**动不了 `latency-500k-8cpu` 那一档**

三处都在 h1 动态热路上，**都不改一个字节的输出**（18 种请求形状逐字节相同）。真实工作点
（8 条循环、`taskset 10-17`、`c=1024`、`/baseline11?a=13&b=42`）上，**每请求的用户态指令数
22 836.1 → 20 317.6 = −11.03%**。

**但这一档要的不是 11%。** `latency-500k-8cpu` 给 8 个线程、目标 500 000 rps ⇒ 每请求得
**≤16 µs**；本仓那一格是 **30.65 µs**（同档头名 14.56~15.63，最好的真框架 hical **18.60**）。
而指令数**只算用户态** —— 系统调用那半边（10~12.5 µs）一行不动。按本仓实测的换算
（约 2 000~3 000 指令 ≈ 1 µs 用户 CPU）⇒ −2 518 指令只值 **−0.8 ~ −1.3 µs**，对 30.65 µs 的
总账 ≈ **−3 ~ −4%**。**微优化在这一档几乎没有杠杆**，理由见本节最后那一小节。

#### 三处改动

| # | 位置 | 原来 | 现在 |
|---|---|---|---|
| E2 | `src/web/uvcpp_http_server.cpp` 的 `find_handler` / `find_stream_handler` | `std::string p = path;` 再 `p.substr(0, q)` —— `path` 来自请求行，长度常超过 SSO 的 15 字节 ⇒ **每次调用一次堆分配 + 一次 `free`**（两个函数各一次/请求） | 只算剥掉查询串后的**长度** `n`，比较用 `path.compare(0, n, r.path)`（不构造子串） |
| E3 | `src/web/uvcpp_http_response.cpp` 的 `to_string_into` | 状态行 + **每个响应头各 4 次 `append`**（`_M_append` 933 次/请求），中间还要零填充 | `est` 补齐成真上界（原来漏算了 `content-length` 那一段），一次 `resize` 出头部区间，`memcpy` + 立即写字节直填，最后 `resize` 回真实长度 |
| E4 | `src/webapp/uvcpp_web_util.cpp` 的 `web_parse_query` | 先 `substr` 出 `kv` 再切两刀，然后**每个键、每个值各调一次** `web_url_decode`（每次还要两次 `find`） | 整串只扫一遍 `%`/`+`；一个都不出现时键值直接在 `query` 上切片、**不做解码**，也不用中间 `std::string` |

#### 判据一：逐字节（18 种请求形状，0 处不同）

`/tmp/latrig/bytes.sh` 对改前/改后两个 `.so`（同一份入口二进制）各抓一遍。形状：
`base`、`Accept-Encoding: gzip` / `deflate, br`、`HEAD`、百分号编码（`q=a%20b&x=1+2`）、
裸键（`?a&b=1`）、空段（`?a=1&&b=2`）、`?=v&k=`、无查询串、空查询串（`?`）、
`/json/50?m=6`、`/json/1?m=2`、`/json/0?m=0`、404、`/`、`/pipeline`、`OPTIONS`、keep-alive。
**18 个应答逐一比对：0 处不同**（只把 `date:` 那一行的值掩掉）。

这一条是"这类改动允许做"的**准入判据**：序列化路径一动，逐字节相同就不再是"没坏"，而是
"没变"。

#### 判据二：确定性指令数（callgrind，真实工作点）

`cg8.sh` 的形状：valgrind + `--instr-atstart=no` 起服务，`h2load -c 1024 -m 1` 先打
2 000 个热身（不计入），再打 **20 000 个**、其间 `callgrind_control -i on` / `-d`。

| 臂 | 窗口里的请求数 | 自计总指令 | 指令/请求 |
|---|---:|---:|---:|
| 改前 #1 | 22 000（**热身那 2 000 个漏进了窗口**） | 494 196 237 | 22 463.5 |
| 改前 #2 | 20 000 | 456 721 445 | **22 836.1**（诚实基线） |
| 改后 | 20 000 | 406 352 585 | **20 317.6** |
| | | | **−2 518.4 = −11.03%** |

**改前那一臂必须跑两遍**，而且第一遍的窗口里混进了别的东西：它的自计总数除出来正好是
**22 000** 个请求（= 2 000 热身 + 20 000 计数），而 `do_lookup_x` / `_dl_lookup_symbol_x` /
`_dl_relocate_object` / `ossl_fnv1a_hash` 这四个**一次性**的动态链接/lazy binding 函数只在
第一遍里出现，合计 **384.5 指令/请求** —— 两遍改前差 1.7%（≈388/req）几乎全由它解释。
**所以用来比的是改前 #2。**

逐函数对得上（callgrind 的**调用次数是精确的**，即使名字被 mangle 掉）。下表是自计开销
变化最大的 16 项，**合计 −2 518.4 /请求，等于总差**：

| 函数 | 改前 #2 | 改后 | Δ | 归谁 |
|---|---:|---:|---:|---|
| `basic_string::_M_append(const char*, size_t)` | 933.1 | 157.1 | **−776.0** | E3 |
| `__memcpy_avx_unaligned_erms` | 987.9 | 660.8 | **−327.0** | E3 |
| `web_url_decode` | 258.0 | **0.0** | **−258.0** | E4（不需要解码就一次不调） |
| `web_parse_query` | 722.0 | 519.0 | **−203.0** | E4（去掉 `kv` 白拷与逐段 `find`） |
| `basic_string::find(char, size_t)` | 422.0 | 278.0 | −144.0 | E4 |
| `__memchr_avx2` | 361.0 | 247.0 | −114.0 | E4 |
| `_int_free` | 617.1 | 509.2 | −107.8 | E2 |
| `malloc` | 495.1 | 405.4 | −89.7 | E2 |
| `find_handler` | 133.0 | 47.0 | −86.0 | E2 |
| `find_stream_handler` | 123.0 | 38.0 | −85.0 | E2 |
| `free` | 432.7 | 354.8 | −78.0 | E2 |
| `basic_string::_M_construct<char*>` | 161.0 | 87.0 | −74.0 | E4 |
| `to_string_into` | 581.2 | 515.3 | −65.9 | E3 |
| `???:0x000000000495c060`（`append` 的 PLT 桩） | 60.0 | 10.0 | −50.0 | E3 |
| `???:0x0000000005297260`（libstdc++ 内 `memcpy` 的 PLT 桩） | 68.3 | 20.3 | −48.0 | E3 |
| `basic_string::_M_replace_aux`（**新增**） | 0.0 | 52.0 | +52.0 | E3：最后那次 `resize` 回真实长度 |

**分配器那四行合起来 −307.5 /请求，正是 E2 去掉的那两次分配 + 两次释放**（这是 E2 的
独立见证：指令数按函数归因，与"字节没变"是两条互不相干的证据）。

**那些 `???:0x…` 形状的行是 PLT 桩** —— `fn=` 里名字是个**字面地址**。要靠 caller 归因才
认得出它们是谁（`/tmp/latrig/{callers,edges}.py`）。**直接 `sed` 看某一段 `fn=` 块会得出
"`to_string_into` 每请求只 append 一次"这种错结论**：callgrind 按 caller 上下文**把同一个
函数拆成好几块**，只有加总才是真数。

#### 判据三：用例

`build-all` 干净重编后 **127/127 通过**（另：`build-yyjson` 93/93、`build-brotli` 92/92、
Linux 默认档 47/47）。

#### 端到端这一次**没有作证据**

同一形状的 A/B 本来要按老规矩交错跑，但这台机器上**用户自己的两个 vitest worker**
（`MainThread` 一串 node 进程）以 200~296% CPU 漂在 `0-17` 上 —— 按本仓的规矩**不动别人的
进程** ⇒ 端到端这次分辨不了库内改动，连"没有反向"的旁证都不给。**本节的三条判据都是确定性
的**（字节、指令数、用例），端到端缺的只是那层陪衬。

#### 为什么说这一档微优化到头了

`latency-500k-8cpu` 的分数形状是
`100 × min(1, rps/500000) × (0.5×cpuScore + 0.25×p99Score + 0.25×meanScore)`，而 `p99` /
`mean` 两项与我们差着三个数量级、恒被钳到 0；8 个线程上 `rps` 又只由 `cpu_per_req` 决定
（8 × 10⁶ / 16 µs = 500 000）。所以这一格近似 `100 × min(1, 16/cpu) × 0.5 × min(1, 14.56/cpu)`，
`cpu = 30.65` ⇒ 约 **12/100**。

要够到分数线得 `cpu ≤ 16 µs`（**−48%**），要够到 hical 那一格（`18.60`）得 **−39%**。
而本节把 h1 的用户态热路翻了一遍：**没有单一主项**（22.5k 指令/请求，top-40 函数合计只占
~45%），剩下能减的池子 —— 路由匹配（`match` 345 + `match_pattern` 164 + `split_path` 138 +
`web_split_path_query` 214 ≈ 860）、请求头搬运（`take_from` 436 + `take_headers_into` 174 +
7 次 `emplace_back` 398 ≈ 1 000）、分配器（≈1 300，约 9 次 `malloc`/请求）—— **全加起来 ~14%，不够
那 39% 的零头**。⇒ **h1 这一层已到本仓能靠微优化碰的边界**（计划里预登记的"风险 2"，
触发条件成立）。

**一条还站着的疑点**（不在"库里某一行"的层面，留给后面）：同样 2.03 次系统调用/请求、
2.01 个包、零锁、零缺页的前提下，本机那台极简参照服务器的**内核态只花 6.4 µs**（用户态
0.6），我们是 10~12.5 µs。SMT 抬价与 iovec 条数这两个解释都做过对照、都被证伪；第三个
解释没有。

#### 复现

```bash
# 逐字节：两个臂各一个 .so，入口二进制同一份（LIBDIR 指向改前/改后那棵 build-docker）
LIBDIR=/tmp/eq/libA /tmp/latrig/bytes.sh /tmp/eq/before
LIBDIR=/tmp/eq/libB /tmp/latrig/bytes.sh /tmp/eq/after
# 断言：18 个 .bin 逐一相同（把 date: 那一行的值掩掉再比）
# 指令数（8 循环 / c=1024，量具 /tmp/latrig/cg8.sh）
/tmp/latrig/cg8.sh 20000 cgb11d     # 改前（跑两遍，第一遍会混进热身那 2000 个请求）
/tmp/latrig/cg8.sh 20000 cgb11c     # 改后
# dump 落在 <label>.out.1（不是 .out）；逐函数自计开销与 caller 归因：
/tmp/latrig/callers.py /tmp/latrig/cgb11d.out.1 '_M_append'
/tmp/latrig/edges.py   /tmp/latrig/cgb11c.out.1 'to_string_into'
```

### 4.23 h1 动态热路再收一轮：一趟扫表、把传输层已经算过的 keep-alive 带下来、路由字面量表（**第十八套装置**，callgrind 指令数 + 逐字节比对）

#### 结论先说：−6.27% 的用户态指令，位置与 §4.22 相同

**19 153.0 → 17 952.0 指令/请求（−6.27%）**，7 个测点全在 h1 动态热路（`/baseline11?a=13&b=42`）。
和 §4.22 一样，这不是 `latency-500k-8cpu` 那一格的杠杆（理由见 §4.22 最后一小节），
它是"确定的百分之几，顺手做掉"。**18 种请求形状的应答逐字节不变**。

#### 七处改动

| # | 位置 | 原来 | 现在 |
|---|---|---|---|
| F1 | `src/webapp/uvcpp_web_request.cpp` 的 `take_from()` | 4 次 `http_get_header()`；它**按值返回** `std::string`，值一过 SSO 线就一次 malloc | 一趟扫表，命中时**写进成员**（成员带着容量概念，实际是每请求新对象 ⇒ 少的是那次返回值） |
| F2 | `uvcpp_http_request::keep_alive` 三态 + `uvcpp_web_request::is_keep_alive()` | web 层每请求重扫头表、按逗号切 token | 传输层 `extract_metadata()` 里算过的 `llhttp_should_keep_alive()` 带下来；`-1` 才回落 |
| F3 | `uvcpp_http_server::send_response()` | 4 次 `has_header()` + 1 次 `get_header()`（后者还造一个 `std::string` 再丢掉） | 一趟扫表拿齐 `connection` / 是否 `close` / `content-length` / `transfer-encoding` |
| F4 | `on_tcp_connection()` 的畸形报文判据 | `host_header_violates()` 与 `transfer_encoding_is_void()` 各扫一遍头表 | 合成 `message_header_violates()`，按名字长度分流（4 / 17） |
| F5 | `uvcpp_web_app::send_response()` | 发送出口又 `r.raw()` 一次 ⇒ 第二次 `sync_meta()` | `raw_after_sync()`（入口处已同步过，中间只补了 `server` 一个头） |
| F6 | `web_parse_query_into()` | 逐段两次 `find(char)`；空向量从 1 长到 2 扩两次 | `&`/`=` 一趟找完、整串只判一次 `%`/`+`；`reserve(4)` |
| F7 | `uvcpp_web_router::match()` | 每条请求都 `split_path()`（vector 分配 + N 份段拷贝）再逐段比 | **全字面量**路由走 `模式 → 候选下标` 表，一次 map 查找；参数/通配路由照旧 |

F2 的判据尤其要说清：`llhttp_should_keep_alive()` 与 web 层原来那段扫表**语义相同**
（1.1 默认保持、1.0 默认关闭、`Connection` 按 token 小写比较），所以这不是"换个来源再赌
一次"，而是"同一个结论别算两遍"。`tests/functional/web_app_request_func.cpp` 的
"keep-alive 判定"一组（手搭请求 ⇒ 走回落那条）原样通过。

#### 判据一：逐字节（18 种请求形状，0 处不同）

`/tmp/latrig/bytes.sh` 对**上一版 `.so`**（10-16 那棵树的产物）与当前树各抓一遍，18 个
`.bin` 把 `date:` 那一行的值掩掉后逐一相同。形状表与 §4.22 相同（含 gzip/deflate、HEAD、
百分号编码、裸键、空段、`?=v&k=`、`/json/*`、404、`/pipeline`、keep-alive）。

#### 判据二：确定性指令数（同一把尺子，五臂）

| 臂 | 自计总指令 | 指令/请求 | 相对前一臂 |
|---|---:|---:|---:|
| 改前 | 383 060 907 | 19 153.0 | — |
| F6 + F1 + F2 | 380 721 131 | 19 036.1 | −0.61% |
| + F3 | 372 259 209 | 18 613.0 | −2.22% |
| + F4 + F5 + F6 的 `reserve(4)` | 359 703 449 | 17 985.2 | −3.37% |
| + `raw_url()` 与 `src_.url` 合一 | 359 039 972 | **17 952.0** | −0.18% |

#### 逐函数对得上（改前 → 改后，指令/请求）

| 函数 | 改前 | 改后 | 说明 |
|---|---:|---:|---|
| `uvcpp_http_response::has_header(const char*)` | 412 | 94 | F3：4 次 → 1 次 |
| `uvcpp_http_response::get_header(...)` | 147 | 0 | F3 |
| `uvcpp_http_server::send_response(...)`（自计） | 169 | 285 | F3 的扫描内联进来了，**与上面两行合并看**：728 → 379 |
| `uvcpp_web_response::sync_meta()` | 310 | 89 | F5：每请求少一次 |
| `uvcpp_web_request::is_keep_alive()` | 134 | 0 | F2 |
| `web_parse_query` → `web_parse_query_into` | 519 | 499 | F6：换了实现，净变化很小（分摊在原函数里的 `find` 与分配迁走了） |
| `std::string::find(char)` | 278 | 168 | F6 |
| `__memchr_avx2` / `__strlen_avx2` | 247 / 268 | 171 / 198 | 上面两条的下游 |

**一处如实记**：F1（`take_from()` 一趟扫）单看是**中性偏负**的（`take_from` 313 → 299，
但它多出来的分支被 `get_header` 的消失抵掉了）—— 真正的收益来自"值不再按值返回"，
而那一段的分配在 `malloc/free` 那几行里，量级与本表的噪声同阶。所以这一条按
"少一条路径"记账，不按指令数记账。

#### 复现

```bash
# 逐字节：上一版 .so 与当前树各来一遍
cp /tmp/latrig/after/libuvcpp.so "$L/build-docker/libuvcpp.so" && /tmp/latrig/bytes.sh /tmp/bytes.before
ninja -C "$L/build-docker" uvcpp && /tmp/latrig/bytes.sh /tmp/bytes.after
# 断言：18 个 .bin 掩掉 date 后逐一相同
# 指令数（8 循环 / c=1024，量具 /tmp/latrig/cg8.sh；dump 落在 <label>.out.1）
/tmp/latrig/cg8.sh 20000 cg8.new      # 改前（跑两遍取第二遍）
/tmp/latrig/cg8.sh 20000 cg8.q5       # 改后
```


### 4.24 `async-db` 换真异步驱动：每请求 CPU 降到线程池那条路的 0.56~0.65 倍（**第十九套装置**，仓外读表量具 + `LD_PRELOAD` 取锁/分配/epoll 计数器）

#### 结论先说：三次交替 A/B，中位 −35%，最好的一对 −44%

池子的异步接口原来只有一种实现：`uv_queue_work` 把一次阻塞查询丢进 libuv 线程池，
每条在途查询占一条工作线程。这条路在 `async-db` 那一档上要付**每请求两次跨线程
交接**（投出去一次、结果回来一次）。现在 PostgreSQL 这条腿改走驱动自己带的异步
协议（`PQsendQueryParams` + `PQflush` + `uv_poll` 盯 `PQsocket()`），查询挂在调用方
自己的循环上，**不占工作线程**，交接次数降为零。回调的形状、线程、返回码都不变
（`uvcpp_db_pool::query` 同一套签名），入口那一侧**一行没改**。

同一份量具、同一条 SQL、同样的在途条数，只换池子的跑法（三次交替、中间 20 s 冷却）：

| 臂 | 三次 `µs/请求 CPU` | 中位 | rps（中位） | 取锁/请求 |
|---|---|---:|---:|---:|
| 真异步（默认） | 46.48 / 36.93 / 42.56 | **42.56** | **69 006** | 9.27 |
| 线程池（`--threadpool`） | 65.62 / 65.69 / 67.90 | **65.69** | 63 807 | 8.08 |
| 同步阻塞（`--sync`，下界） | 24.57 / 27.49 / 24.08 | 24.57 | 65 478 | 4.01 |

**中位比 0.648（−35.2%），最好的一对 36.93 / 65.62 = 0.563（−43.7%）。** 真异步这次
每一对都比线程池低，方向没有一次翻转；但同一臂内的散布不小（native 36.9~46.5），
所以只按中位和最好值说话，不写"每个都低四成"。rps 那两列不是这条改动的目标
（本机是 PG 延迟受限的工作点），只是顺带记下：并发 1024 条在
两种跑法下都跑在同一个平台期上。

量具形状（`LOOPS=8 K=128 N=3 000 000`，`taskset -c 0-7`，`DATABASE_MAX_CONN=256`，
PG `max_connections` 400）：8 条 `uvcpp_loop` 各跑一条线程，每条维持 128 条在途，
只投 N 条、投满为止。读数 = 进程 `user+sys`（`/proc/<pid>/stat` 两拍）除 N。
线程池那臂要 `UV_THREADPOOL_SIZE=256` —— 1024 条在途查询会同时占满线程池；
第一次用 `DATABASE_MAX_CONN=100` 跑时连接不够、5 s 借连接超时，量出一片
`no_connection`，那组数**作废**（不是代码缺陷，是工作点没给够）。

#### 剩下的差额在哪：同并发下只差 6.6 µs，其余是并发本身

`--sync` 是"每循环一条查询、阻塞在 `PQexec` 上"的地板（8 条在飞）。它和真异步在
**128 条在途**时差 18.0 µs，但这个差里混进了并发：sync 这条路构造上给不出 1024 条
在飞。所以在**同样 8 条在飞**（`K=1`，`N=400 000`）下再量一对：

| 臂（8 条在飞） | `µs/请求 CPU` | rps | 取锁/请求 |
|---|---:|---:|---:|
| 真异步 | 29.73 | 64 837 | 9.03 |
| 同步阻塞 | 23.14 | 67 852 | 4.00 |

⇒ **异步机制本身值 6.6 µs/请求**；另外 12.8 µs 是"在途从 8 条涨到 1024 条"买来的
（池子锁 9.0 次/请求而且是有争用的、PG 侧并发、调度），而这一步**没有换来 rps**
（64.8 k → 69.0 k，在噪声里）。这一条对平台那档是有用的判读：**在途条数不是越大
越好**，它只把每请求 CPU 抬高。

那 6.6 µs 由这些组成（逐项量到的，不是估的）：

| 项 | 每请求 | 怎么量的 |
|---|---:|---|
| `epoll_ctl` | **3.0 次**（ADD 1.00 / MOD 0 / DEL 1.99） | `LD_PRELOAD` 拦 `epoll_ctl`/`epoll_wait`（`/tmp/adbrig/epollcount.so`） |
| `malloc` | 60.06 次（sync 51.29，**+8.8**） | `LD_PRELOAD` 拦 `malloc`（`/tmp/c1/memcount.so`） |
| `pthread_mutex_lock` | 9.03 次（sync 4.00，**+5.0**） | `LD_PRELOAD` 拦 `pthread_mutex_lock`（`/tmp/c1/lockcount.so`） |

那 3 次 `epoll_ctl` 里**有 2 次是 libuv 的探针**：`uv_poll_init()` 会先
`uv__io_check_fd()` 试挂一次再摘掉（`libuv:src/unix/linux.c:735-753`），只为验证这个 fd
能进 epoll。真正的注册走 `uv__io_start()` 的 watcher 队列
（`libuv:src/unix/core.c:917`），**在每一轮循环里批量下发** —— 128 条在飞时摊到每请求
不到 1/128，所以在计数里看不见。剩下 1 次 DEL 是 `uv_poll_stop()`。
要再省这 2 次，只有"每个连接留一个常驻 `uv_poll_t`"这一条路（连接换循环时要重建），
本机估下来值 1~1.5 µs/请求，**这一版没做**：它把句柄的生死绑到连接的生死上，
而连接会在分片之间搬家，风险与收益不成比例。另外约 4 µs 落在用户态：每条查询
两个句柄（`uv_poll_t` + `uv_timer_t`）的一生、状态机、`std::function` 与那 8.8 次
分配，逐项没有拆到更细 —— 如实记在这里，不假装账已经平了。

对照一下**旧的线程池那条路**每请求多出来的东西（同样是 `LD_PRELOAD` 量的）：
一次 `uv_queue_work` 的跨线程唤醒 + 工作线程上的一次 `pthread_mutex_lock` /
`pthread_cond_signal` / `pthread_cond_wait`（§4.21 记过
9.2 / 2.0 / 1.0 这笔账，与并发无关）—— 那才是这次要拿掉的东西。

#### 合规上的顺手一件

`async-database` 那一档的 `standard` 规则原文就写着 "Must use an async PostgreSQL
driver with standard connection pooling"，`implementation.md:111` 是
"**Async driver required**"。线程池包一层阻塞 libpq 算不算"async driver"本来有歧义
（§4.21 记过这条），真异步这条路把它做实了。这一条与性能无关，但它是"能不能留在
standard 档"的判据。

#### 一个必须写进契约的坑

真异步这条路上查询的 I/O 是**由那条循环驱动**的。带着在飞的查询 `loop.stop()` ⇒
那几条永远不会落地 ⇒ 池子析构一直等 `work_in_flight` 归零，进程退不出去。
线程池那条路没有这个问题（活在工作线程里跑完就减账）。量具第一版就是按"已完成数"
判停、多投了 K 条，然后卡死在这儿 —— 不是库的缺陷，是用法。判据与约定已写进
`src/db/uvcpp_db_pool.h`（"收尾有一个硬约束"那一段）。

#### 复现

```bash
# 三臂 × 3 次，中间 20 s 冷却（连跑会掉频）
cd /tmp/adbrig && ./matrix.sh            # → matrix.out
# 同并发对照（8 条在飞）
LOOPS=8 K=1 N=400000 MODE=""        ./measure.sh nk1
LOOPS=8 K=1 N=400000 MODE="--sync"  ./measure.sh sk1
# 每请求的系统调用 / 分配
MODE="" ./epoll.sh native                # ADD/DEL/WAIT 次数
MODE="" ./alloc.sh native                # malloc 次数
```

量具 `rig.cc` 直接调 `uvcpp_db_pool::query(loop, …)`，SQL 是入口 `async-db` 那一句
（`SELECT id, name, … FROM items WHERE price BETWEEN $1 AND $2 LIMIT $3`），
本机必须先把静态语料那套放一边 —— 它不碰文件，只碰 PG（`127.0.0.1:55432`，
`items` 十万行、`price` 上**没有**索引）。

#### 这一条**没有**证明的事

- **平台那一格会变成多少**：本机是 PG 延迟受限的工作点，`µs/请求`不能按比例外推
  （§4.21 记过 20 144 rps / 26 ms 与平台 83 890 rps /
  11.77 ms 的差别）。要数字只能等平台跑一轮。
- **在途条数该配多少**：上面量到"1024 条在飞不换来 rps、只换来 CPU"，但池子大小
  与在途条数的调法是 `tuned` 档的技术，我们走 `standard` ⇒ 照 `DATABASE_MAX_CONN`
  定池、不调（§4.21 记着这条判读）。
- **其它后端**：只有 PostgreSQL 这条腿有真异步协议。`insert` 也不在这条路上
  （它要"执行 + 取 `lastval()`"两次往返，完成回调只交一张结果表），仍走线程池。

### 4.25 h2 请求头的「按条数预留」：issue #26 的前提不成立（**负结果**，`LD_PRELOAD` 分配计数器 + 逐请求 A/B）

issue #26 的建议是「HEADERS 帧里 `frame->headers.nvlen` 是精确已知的，按它 `reserve()`
就能省掉 1→2→4→8 的扩容」。量下来的结论是**两处前提都不对**，改动没有采纳（已回退）。

**装置**：一个最小的 h2c 服务（`GET /x` 回 `{"ok":1}`）链**共享库**，`LD_PRELOAD` 分配
计数器在压测前后各打一次快照，`h2load -c 32 -m 10 -n 20000` 打 `127.0.0.1`。三臂交替各跑
两轮，服务端钉在 CPU 0-3，压测端 4-11。

| 臂 | 改动 | malloc/请求 | 字节/请求 |
|---|---|---|---|
| A（基线） | 无 | **27.160**（54 3201/20000） | 9 919.8 |
| B | `reserve(frame->headers.nvlen)`（封顶 64） | 27.160（54 3203） | 9 926.4 |
| C | `reserve(8)` 常量 | 27.160（54 3203） | **10 175.8** |
| D | 插入点前补 `http_reserve_headers()`（`reserve(4)`） | 27.160（54 3207） | 9 919.8 |

**B 与 A 逐次分配数完全相同**，原因是第一条前提不成立：nghttp2 的**收方向**从不调用
`nghttp2_frame_headers_init()`（`_local_deps/nghttp2/lib/nghttp2_session.c` 里它只出现在
提交侧），收到的 HEADERS 帧里 `nvlen` 恒为 `0` —— 在 `on_begin_headers` 里加一行
`fprintf` 实测三个请求全是 `nvlen=0`。`on_frame_recv` 也一样。

第二条前提同样不成立：**请求头表在第一个伪头那里就已经 `reserve(4)` 了**。`:authority`
被 `handle_pseudo()` 用 `set_header("host", …)` 落进表里，而 `set_header` 走的是
`http_reserve_headers()`（`capacity() == 0` 时 `reserve(4)`）。插桩实测 `handle_regular()`
第一次进 `push_back` 时是 `cap=4 size=1`。于是普通请求（h2load 发 2 个常规头）**一次扩容
都没有**，这正是 D 臂零效果的原因；C 臂反而多花 256 字节/请求（预分配 8 个槽、少用 6 个）。

**真实浏览器那种 10 个常规头**的请求确实会付两次扩容（4→8→16），但那最多值 2 次分配
（27 → 25），而任何常量预留都要**无条件**先付一次分配并长期占住容量 —— 换不来净收益，
所以保持现状。这条结论与 §4.21 那一类一样：**先量再改**，问题单里的推断也可能是错的。

**这一条没有证明的事**：别的 nghttp2 版本是否也如此（本仓 `_local_deps` 那份的行为是
「收方向没有 nvlen」；上游没有文档承诺这个字段在收方向有值）。真要用它，得先把版本钉牢。


## 5. 结果三：稳定性

10 分钟持续压测（动态路由 + 连接 churn + WebSocket 混合）：

| 项 | 读数 |
|---|---|
| 总请求 | **38 404 681，0 错误** |
| RPS | 64 008 |
| 延迟 | p50 **1 ms** / p90 1 ms / p99 **2 ms** / max **14 ms** |
| RSS 漂移 | **0.2%**（90.3 → 90.5 MB） |
| 句柄 | 252 → 254 |
| 连接 churn | 9 810 次建连 / **0 失败** |
| WebSocket | **7 804 条会话、23 412 帧 / 0 失败**，回收计数与建连数完全对上 |

另外单独做了**分段归因**（每段只做一件事，各自算 RSS 斜率）：只发内存型请求
（每请求新建连接）**−0.01 MB/min**、只建连/断开（3 757 次）**+0.01 MB/min**、只做
WebSocket 建连/回显/断开（2 733 轮）**+0.07 MB/min**、完全不发请求 **0.00 MB/min**。
四段全平 ⇒ 没有随时间累积的增长，长跑那条 0.2% 是分配器膨胀后收敛，不是斜坡。

> 这份归因第一次跑出来是 `19.52 MB/min` 的"持续增长"。真因不在被测对象：采样是按
> **进程名**取第一条匹配，而当时机器上还跑着另外两台同名的被测进程，样本里不存 pid ⇒
> 采样在进程之间跳了。证据是那条序列呈**单次 34 MB 台阶后永久平**（跳变，不是斜坡），
> 换成**按 pid 锚定**的采样后全程 9.47 MB 不动。写在这里是因为这类装置缺陷会让读数
> 骗人，而它长得和真泄漏一模一样。

---

## 6. 与 Hical 的对照

对照对象是 **[Hical61/Hical](https://github.com/Hical61/Hical)** —— 一个 C++20/26 的
Asio 框架，同样面向「百万空闲长连接」。它自己维护了一份性能报告（该仓库
`docs/performance_report.md`），其中 **§2.8「空闲长连接内存优化」** 给出的正是同一量：
**每条空闲连接的内存**。所以两边不用在两套口径之间换算，可以直接比。

Hical 自己在 §2.8 里给的账（v2.6.4 → v2.6.5）：

| 优化项 | 优化前 | 优化后 | 每连接节省 |
|---|---|---|---|
| `readBuf` 借还 | 连接常驻 8 KB `std::string` | `ReadBufferPool` 按需借还，空闲时不持有 | ~7.5 KB |
| `inputBuffer_` 懒分配 | 连接建立即分配 `PmrBuffer`（~2 KB） | `std::optional<PmrBuffer>`，第一次读才创建 | ~2 KB |
| **合计** | **~17.44 KB** | **~8 KB**（省约 55%） | |

同表给出百万连接量级：**~16.6 GB → ~7–8 GB**。
§2.9（v2.6.6）又加了一档：空闲连接 **+256 B**（协程帧栈），换来 `epoll_ctl` 调用数降 71.8%。

| 实现 | 每空闲连接 | 百万连接 |
|---|---|---|
| Hical v2.6.4（优化前） | ~17.44 KB | ~16.6 GB |
| Hical v2.6.5 / v2.6.6 | ~8 KB（v2.6.6 再 +256 B） | ~7–8 GB |
| **libuvcpp 1.1.33** | **4.62 KiB**（4 734 B） | **4.42 GiB** |

> Hical 那两格沿用**它的原文标法**（`KB` / `GB`）；它实际是二进单位，见下面第一条。

- 对本库 vs Hical **优化前**：**轻约 3.8×**（每连接少约 12.8 KiB）。
- 对本库 vs Hical **优化后**：**轻约 1.7×**（4.62 KiB vs ~8 KiB）。

**⚠ 这个 1.7× 有一处口径不确定，写清楚免得被读成强结论。** Hical 在那句话里同时注明
「内核侧 TCP 缓冲 ~4 KB/连接不可优化」。**本文的 4.62 KiB 是进程 RSS 增量，只含用户态**；
如果 Hical 的 ~8 KB 里已经含了那 ~4 KB 内核缓冲，那么同一口径下它剩下的用户态部分约
4 KB，两者**接近持平** —— 差别是本库的机制里压根没有常驻读缓冲，而它需要一套
`ReadBufferPool` 借还来达到同一格。该文档没有把这个口径写明，所以两种读法都列在这里，
不单选对本库有利的那个。**优化前那一格（17.44 KB）没有这个歧义。**

**其余可比性说明**：

- 两边都是**外推**（都撞端口/内核墙），所以都是"斜率可信、截距不可跨机器比"。截距差异
  明显（本机 9.95 MB，因为这台还带着静态缓存、会话表与已初始化的协议层）。**斜率才是
  可比的量**，上表据此下结论。
- **单位口径其实同一个**（这里先前写成"不同"，是我没查）：Hical 标的是 `KB` / `GB`，但它
  那几个数**只在二进读法下自洽** —— `17.44 × 1024 × 10⁶ B = 16.63 GiB`，正好对上它写的
  **~16.6 GB**；按十进读成 `17.44 KB` 算出来是 `16.24`，对不上。所以它的 `KB` 是 KiB、
  `GB` 是 GiB，与本文同口径，**上面那两个倍数不用折算**。
- **平台不同**：Hical 的数据出自它自己文档所述环境（Linux VM），本文是 Windows / MSVC
  / 环回。跨平台比较请带上这一条。

---

## 7. 这一页不是什么

- **不是跨平台的定论**，也不是跨项目的绝对排名 —— 见第 6 节最后三条。
- **不是单核之外的成绩**。上面所有吞吐都是**一个事件循环线程**（静态那几条走工作池）。
  要横向扩就起 N 个进程。别把 75 k 当成"每核 75 k 且不可再扩"。
- **不是 TLS 读数**。TLS 的稳态代价另有一组（约 −23% ~ −30% RPS，256 KB 响应受 AES-GCM
  单核吞吐限制降到 119 MB/s）；那一组的基线对照**归因未闭合**，所以没有放进这一页。

---

## 8. 复现方法

测量装置是一组独立脚本（Node + Python，跑在靶场进程之外），不随库发布。方法本身足够
简单，按下面三步就能复刻：

1. **建连**：分档建立 N 条 TCP 连接（N = 0 / 8k / 16k / 24k / 32k / 40k / 48k / 55 000），
   每条建好后发一个请求并读回响应 —— **逐条复检**，失败的连接不计入 N 且要单独报数。
2. **采样**：每档稳定后读被测进程的 RSS（Windows 是 `WorkingSet64`，Linux 读
   `/proc/<pid>/status` 的 `VmRSS`）。**按 pid 采样，不要按进程名** —— 见第 5 节那个坑。
3. **拟合**：对 (N, RSS) 做最小二乘，报**斜率、截距、R²、每点残差**。R² 不接近 1 就说明
   这条直线不成立，此时不要外推。

吞吐那一组用 `autocannon`（15 s/档，同机）；长跑那组是 10 分钟的自建压测循环，同时统计
错误、延迟分位、句柄数与 RSS 漂移。

---

## 9. 出处

- **libuvcpp 侧**的全部数字：本库在 `534e4ed`（1.1.33）上构建出的靶场，方法如上。
- **Hical 侧**的数字：`Hical61/Hical` 仓库的 `docs/performance_report.md`，§2.8 / §2.9。
  引用的是该项目的**自报**数据，本文没有在其平台上复跑过；其测试环境见该文档 §1。
- **平台侧的读数（4.5）**：HttpArena 仓库里的 `site/data/results/libuvcpp.json` —— 由平台的
  bot 提交回推送条目的那条分支，六轮（第三轮当天两次）分别落在
  `c6f0b3e`（2026-10-10，20 档）、`e53db82`（2026-10-12，26 档）、
  `6cf7819`（2026-10-13，42 档，钉 `2d5fe740`）、`2711a96`（2026-10-13，42 档，钉
  `c8950ae`）、`16c11f7`（2026-10-14，42 档，钉 `6eede33`，被测树 `ae437de`）、
  `6fadb86`（2026-10-15，42 档，钉 `8150720`，被测树 `a19557f`）；每一轮读哪一版库与哪一版
  条目，可以从该提交里的 `frameworks/libuvcpp/Dockerfile` 与 `main.cc` 直接看出来 ——
  这也是 4.5 那几条归因的判据。**被测树 = 该结果提交的父提交**（bot 把结果推在被测的那棵树
  顶上），平台的 `Benchmark PR` 跑在 `main` 上、checkout 的是
  `refs/remotes/pull/<n>/head`。原始日志在同仓
  `site/static/logs/<档>/<连接数>/libuvcpp.log`。
  参考机与核绑定见该仓 `site/content/docs/hardware/_index.md`，档位定义见
  `scripts/lib/profiles.sh`。家族名次与分数读
  `https://www.http-arena.com/badge/index.json`。