lily-nest QPS 压测报告（v0.3.3 · AMD64 本地回环）

• 测试机：SULY-HP8B6EA（HP EliteBook 845 G10 · AMD Ryzen 7 PRO 7840U 8C/16T · 30GB DDR5 · Linux 7.1.9-arch1-2 · CPU governor performance · amd_pstate 标称上限 5.13GHz（硅片 Fmax，实测单核封顶 4.84GHz 见下文） · glibc 2.44 · rustc 1.96.0）
• 被测试版本：lily-nest v0.3.3，git commit f92c988（fix(note): repair markdown table rendering; bump to v0.3.3）
• 测试方式：设备本机回环（127.0.0.1），服务从项目根目录启动（配置按 cwd 读取）
• 工具：wrk f8eb608（HTTP/1.1）+ oha 1.14.0（HTTP/1.1、HTTP/2），均 -d10s 时长
• 配置：config.toml 已启用 ./certs/example.com.{pem,key} 示例证书（[tls] 取消注释）
• TLS/证书：example.com 自签证书；HTTP/2 走 ALPN 协商（oha 默认 h2，rustls TLS 1.3）；客户端不验证证书（wrk 默认不校验、oha 加 --insecure）——与真实部署 CF 场景无关，本报告只测服务端 TLS 开销

构建矩阵

注：-C lto=fat 不能放 RUSTFLAGS（proc-macro crate 在 stable 上会报 lto cannot be used for proc-macro crate type without -Zdylib-lto），须走 cargo profile（--config 'profile.release.lto="fat"'）。

测试方法学（可复现）

所有测试统一约定，读者可按下列命令逐条复现：

# wrk（HTTP/1.1，keep-alive 长连接，默认行为）
wrk -t8 -c64 -d10s --latency <url>

# oha（默认 HTTP/2，走 ALPN 协商；h1 用 --http-version=1.1）
oha --insecure -c256 -z 10s --no-tui <url>

• -d10s / -z 10s：所有组固定 10s 时长；--latency 已开启（延迟分布为记录值）
• 无一例使用自定义 Lua 脚本/自定 header，User-Agent 为工具默认值
• 连接模型：wrk 与 oha 均为 keep-alive 复用连接（压测标准做法，度量的是稳态请求处理而非连接建立成本；连接建立成本见「已知局限」）
• 证书：服务端 example.com 自签证书（./certs/），客户端不校验（wrk 默认、oha --insecure）——测的是服务端 TLS 开销，客户端校验与否不影响该指标
• HTTP/2：由 ALPN 协商（rustls TLS 1.3 + h2），非明文 h2c
• error rate：wrk 输出含 Errors 计数，本次所有组压测无报错记录（完整 HTTP 状态码统计见「已知局限」）
• 原始数据：远程 /tmp/bench/*.txt（wrk/oha 完整输出存档）

结果（Req/s）

* README 参考环境：Ryzen 7 7840HS + release + LTO + force-http（v0.2.8-beta）

延迟（wrk -t8 -c64）

oha -c256 h2 /health P50/P99：标准 0.79/3.07ms → 极端 std 0.70/2.13ms → force-http 0.63/2.02ms。

结论

1. 极端优化收益（同为 HTTPS）：wrk +9~11%，oha h1 +13%，oha h2 +23%（高并发下最明显）。
2. TLS 开销（同构建，HTTP vs HTTPS）：wrk t8c64 ~13%，oha h2 ~10%。
3. vs README v0.2.8 参考：v0.3.3 极端 force-http 达参考值 76%（health wrk）、81%（root wrk）、89%（oha h2 health）、104%（oha h2 root）；差异与 CPU 功耗墙（7840U vs 7840HS）高度相关；剩余部分未做 middleware A/B 验证，实际可能来自 v0.3.3 新增中间件/安全头/缓存检查与系统环境差异——该拆分为推断而非实验直接证明。
4. 首页 /（~11KB 缓存 HTML）QPS 约为 health 的 3/4，吞吐 3.4~4.8 GB/s。

与 README 基准机（7840HS）的差距分析

README 参考值来自 Ryzen 7 7840HS（35-54W 高性能档），本机是 Ryzen 7 PRO 7840U（15-30W 低功耗档）。两者同为 Zen 4（Phoenix）8C/16T、16MB L3、5.1GHz 单核睿频，唯一本质差异是功耗墙 → 持续全核频率。

本机实测（压测负载下全核频率采样）：

7840HS 典型持续全核频率：4.4~4.6 GHz（45-54W 配置，Cinebench R23 多核约 17,000-18,000；7840U 约 13,500-14,500，差约 +20~25%）。

频率实测曲线（本机，每核独立烧核进程，各采样 ~2.4s）：

ACPI/CPPC 声明的 5.13 GHz 是硅片理论单核 Fmax，不是能全核跑到的频率；且本机 HP 固件把最高档（amd_pstate_highest_perf）限制在 196/255，实际单核封顶 4.84 GHz。7840HS 单核上限同为 5.1 GHz（OEM 封顶视机型），但 45-54W 下全核持续典型 4.4~4.6 GHz——全核频率同样远低于单核睿频。

差距归因（v0.3.3 极端 force-http vs README v0.2.8）：

结论：wrk 的 19~24% 差距中约 3/4 由 CPU 功耗墙（全核 3.85 vs ~4.5 GHz）解释，与时钟比预测（≈−14%）一致；剩余 ~5-10% 未做开启/关闭中间件的 A/B 实验，属推断成分——可能来自 v0.3.3 新增中间件（CORS/安全头层）与系统环境差异。oha h2 场景差距仅 11%、首页甚至反超 → 代码整体无退步。同样代码放到 7840HS 上，预计 wrk /health 约 58~62 万（v0.2.8 的 65.7 万含更轻的中间件栈）。

note 端点回环压测（主流量，force-http 极端优化版，缓存态）

• 路由：/note（列表 5.3KB）、/note/{slug}（详情 5.7KB）；当时仅 1 篇文章：梨记（lily-note）模块上线（slug=20260620160514）——多文章场景见下文实机段（8 篇）
• 压测前已预热：首次请求才执行读盘 + pulldown-cmark 渲染，之后走内存缓存（详情缓存上限 20 条，满则淘汰最旧），以下均为缓存态稳态

结论：主流量端点性能与 /health 同级（缓存态 bytes::Bytes 零拷贝）：c64 时 47~49 万 Req/s（P50 ~110µs），c256 时 59 万；列表与详情几乎无差异。首次访问的渲染成本被缓存摊平，压测反映的是稳态承载能力。

HTTPS（std 极端优化版 :8443，example 证书，缓存态）

TLS 开销 18~28%，高于 /health 的 ~13%——响应越大每请求加密数据越多，rustls 加密成本随负载线性增长；延迟 P50 仅 +20~30µs。

局域网压测（RJ45 直连 1Gbps）

• 拓扑：X270（Intel I219-V · enp0s31f6 10.99.0.1/24）═ 网线 ═ HP EliteBook 845 G10（ASIX AX88179 USB 千兆网卡 · enp197s0f3u1c2 10.99.0.2/24）；两端 NM 手工改为 static（Plasma 会无限重试 DHCP，必须手动配）
• 服务：HP 上 force-http 极端优化版（:8880），客户端在 X270（wrk 本机 /usr/bin/wrk，oha 从 HP scp 过来）
• 链路：1000Mb/s 全双工，实测有效吞吐上限 ~110-112 MB/s（千兆线速 ~119MB/s）；ping RTT ~2.5ms（HP 侧 ASIX AX88179 USB 网卡驱动 + EEE 省电导致，直连线正常应 <0.5ms）

结论：

1. 大响应（首页/CSS，~10KB+）直接撞千兆线速：~9.5-10.9k Req/s @ ~110MB/s。与 README 的 LAN 参考（12,180 @ 109MB/s）吞吐一致，Req/s 略低只因 v0.3.3 首页更大。
2. 小响应（health，~670B）瓶颈不在链路：并发从 64→1024，QPS 107k→140k 趋平（吞吐 72→94MB/s），受"连接数 × RTT"和 USB 网卡驱动限制，未达 health 的线速上限（~178k @ 119MB/s）。
3. 回环 vs 局域网：health 500k→~140k（网络栈/RTT 主导），root 422k→~9.5k（纯链路饱和）。

HTTPS 局域网（std 极端优化版 :8443，example 证书）

HTTPS vs HTTP（局域网）：小响应 health 低 ~8-16%（TLS 每请求加密开销，高并发更明显）；大响应（线速受限）几乎无差（−0.3%）。与回环测得的 TLS 开销 ~13% 一致。

红米 AX5 JDC（两端有线接路由器，同网段二层路径）

延迟变化：health P50 0.40ms→2.71ms（c64）、4.5ms（c256）；root P50 6.64ms→8.52ms。

结论：红米 AX5 JDC 是显著瓶颈，且只有小包 QPS 能暴露它——iperf3 大流测试带宽仍有 860Mbps+，但小请求场景（每请求 5-6 个小包）被路由器的软转发打穿：QPS 掉 63-80%，P50 延迟涨 6-7 倍（health 的 QPS ≈ 连接数 ÷ 路由器 RTT）。大响应（~10KB）受包速率影响较小，只掉 29%。

路由器配置：红米 AX5 JDC（高通 IPQ6000 · 4×Cortex-A53 @1.44GHz · aarch64 · OpenWrt 6.12.69）。NSS 硬件加速未启用（纯 CPU 软转发），SQM（CAKE 队列）挂 PPPoE：下行限 920Mbps。瓶颈构成：IPQ6000 conntrack 小包软转发 + CAKE 队列调度延迟叠加——大流带宽不受小包排队影响，所以 iperf3 看不出问题；且 SQM 上行限速 即公网回源的实际出口上限。

---

实机部署：玩客云 v0.3.3（OneCloud · ARMv7 局域网实测）

• 部署机：CHIX-OneCloudA（Amlogic S805 · Cortex-A5 四核 1.54GHz · 1GB DDR3 · eMMC · Arch Linux ARM · 自编译内核 7.1.8-suly）
• 构建：X270 交叉编译 armv7-unknown-linux-gnueabihf，CARGO_PROFILE_RELEASE_LTO=true + CODEGEN_UNITS=1 + PANIC=abort + STRIP=true，target-cpu 默认（generic armv7-a+vfpv3-d16，交叉编译不用 native），无 embed-bitcode；链接器 arm-linux-gnueabihf-gcc；二进制 8.0 MB（stripped）
• 服务：HTTPS :443（release 强制 TLS）+ cloudflared + ddns-go + WireGuard，常驻内存 2.2M 峰值（口径：systemctl MemoryCurrent，即 RSS；实测 22 轮不同端点压测后峰值 32M 不随轮次增长，无泄漏迹象）
• 拓扑：X270（Intel I219-V 有线 · 192.168.0.114）═ 红米 AX5 JDC ═ 玩客云（192.168.0.218），与上文"红米 AX5 JDC"同型
• 对比参考：7840U 数据为 RJ45 直连（无路由器），玩客云为过路由器——差距含路由器因素，详见结论

结论：

1. 小响应（health ~670B）7k~8.7k QPS：c64→c256 几乎持平（8,710→8,615），c1024 下滑（7,028）——CPU 在 c256 已饱和。vs 7840U 过路由器同场景（20,916）约为 42%，差距主体是 Cortex-A5 1.54GHz 的 CPU 能力（单核性能约为 Zen4 的 1/8~1/10），路由器因素叠加上限。
2. h1 vs h2 无差（8,253 vs 8,264）：瓶颈在 CPU 单核处理，协议层优化吃不到。
3. 大响应：首页 2,658 Req/s（41.4MB/s）约为 7840U 直连的 28%，接近路由器+带宽上限；css 1,118 明显低于首页——ServeDir 无内存缓存，每请求读 eMMC + 文件系统开销，在玩客云上被放大（7840U 上被强 CPU 掩盖），若在意可给静态资源加内存缓存。
4. 全程无崩溃；v0.3.3 在 1.5GHz 嵌入式设备上 HTTPS 服务稳定，资源占用极低。

已知局限与后续

按"严格可复现实验报告"标准自查，本报告存在以下有意为之的取舍，如实记录：

• 单次测量、无方差：每组跑 1 次而非 n=5 取 median；CPU 频率实测前 10s 3.9GHz → 60s 滑向 3.5-3.6GHz（见频率采样表），单次 10s 测量精度约 ±5%，结论方向不变但具体数值有该量级噪声
• 未测连接建立成本：全部为 keep-alive 稳态（wrk/oha 默认复用连接），未单独测 TCP/TLS 全握手 / 再次握手的建立延迟——个人站点场景影响小
• 未做 middleware A/B：v0.3.0 新增中间件的性能影响为推断，未做开启/关闭对照
• cold-cache 未单测：note 段均为预热后的缓存态稳态；首次访问（读盘 + pulldown-cmark 渲染）成本被缓存摊平，无 cold-cache / 拥塞淘汰的专项数字
• 写入路径未测：POST/PUT/DELETE /api/v1/notes 未压测——Markdown 写入 + fsync + 缓存失效在玩客云 eMMC 上可能才是写入瓶颈（读取路径表现已充分）
• 饱和点曲线不完整：并发档位仅 c64/256/1024，缺低并发区（c1~c32）与更高档的吞吐-延迟拐点曲线；已有数据可见 c256 附近进入饱和区（c64→c256 提升、c1024 下滑）
• error rate 未单列：压测无报错记录，但未按 HTTP 状态码 4xx/5xx/timeout 分档统计——"无崩溃"≠"无 error"，正式的 error rate 指标留待后续

后续若要升级为"工程级 benchmark"（右列优先级）：n=5+median | 完整命令已补（见「测试方法学」）| error rate 分档 | 低并发饱和曲线 | note cold-cache + 写入路径。

---

数据：chixiaoshu & Suly 实测 · 文章：AI 梨梨协助