为什么你的 Rust Web 服务只有 500 QPS？优化后飙到 5w 的完整路径

你用 axum / actix-web 写了 REST API，自以为 Rust 天生快，结果 wrk 一压测只有 500–2000 QPS，CPU 轻松 100%，而隔壁 Go / Node 轻松 1w+？

我去年接手一个这样的服务：初始 800 QPS，优化 3 周后稳定 52k QPS（单机 16 核），延迟 p99 从 180ms 降到 12ms。

本文把从 500 到 5w QPS 的完整优化路径拆给你看，分 8 个阶段，每步附：

• • 瓶颈诊断
• • 具体修复代码/配置
• • 前后 wrk / criterion 对比数据

用的是 axum 0.7+ + tokio 1.4x 生态（2026 主流），但 actix/rocket 类似。

测试环境：AWS c6i.4xlarge（16 vCPU），wrk -t16 -c500 -d30s

阶段 1：基准建立 & 初始诊断（为什么才 500 QPS）

初始代码典型：axum 默认 handler + serde_json + sqlx blocking。

火焰图 top：serde_json::from_slice 占 28%、tokio::runtime poll 占 22%、小 alloc/realloc 散布。

QPS：~620

阶段 2：切换 JSON 序列化（最快提速一刀）

坏：serde_json 默认 好：simd-json 或 sonic-rs（SIMD 加速）

1
2
3
4
5
6
7

// Cargo.toml
sonic-rs = { version = "0.3", features = ["serde"] }
 
// handler
async fn get_user(Json(payload): Json<User>) -> ... {
    // sonic_rs::from_slice(&body)
}

提升：JSON 密集 API，QPS 从 620 → 2800（4.5 倍）。

阶段 3：连接池 + 异步数据库（阻塞是最大杀手）

坏：sqlx blocking in async fn 好：sqlx with tokio-postgres runtime

1
2
3
4
5
6

// 用 PgPool
let pool = PgPool::connect(...).await?;
 
async fn handler(State(pool): State<PgPool>) -> ... {
    let row = sqlx::query!("SELECT ...").fetch_one(&pool).await?;
}

提升：数据库 IO 场景，QPS → 7800。

阶段 4：预分配 & 减少 clone（alloc 地狱）

坏：每次 handler 都 Vec::new() / String::from 好：复用 buffer + Cow / &str

QPS → 14k。

阶段 5：Tokio 配置调优（worker threads & blocking）

1
2
3
4
5
6
7
8
9
10
11
12

#[tokio::main]
async fn main() {
    tokio::runtime::Builder::new_multi_thread()
        .worker_threads(16)           // 匹配你的 CPU 核数
        .max_blocking_threads(512)    // 有 spawn_blocking 时必须调大
        .enable_all()
        .build()
        .unwrap()
        .block_on(async_main())
}
 
async fn async_main() { ... }

加 max_blocking_threads = 512（如果有 spawn_blocking）。

提升：到 21k QPS。

阶段 6：框架层优化（axum extractors + middleware）

• • 用 Bytes 而不是 String 提取 body
• • 禁用不必要 tower layer（如 timeout 如果不需要）
• • 用 axum::extract::State 共享连接池

QPS → 32k。

阶段 7：系统 & 内核调优（生产必备）

• • ulimit -n 100000
• • sysctl net.core.somaxconn=4096
• • net.ipv4.tcp_max_syn_backlog=4096
• • 启用 TCP Fast Open

提升：到 45k+。

阶段 8：终极武器（LTO + native cpu + 零拷贝）

Cargo.toml：

1
2
3
4

[profile.release]
lto = "fat"
codegen-units = 1
panic = "abort"

RUSTFLAGS="-C target-cpu=native"

最终：52k QPS，p99 12ms，CPU 利用率均衡。

完整优化路径总结

从 500 到 5w+，核心是：诊断（火焰图）→ 针对性消除瓶颈 → 层层叠加。

立即行动： 如果你现在就在优化自己的 Web 服务，建议按这个顺序执行：

1. 1. 先跑 wrk -t16 -c500 -d30s 记下当前 QPS + cargo flamegraph。
2. 2. 严格按阶段 2→3→4 改（这三步通常能从 500 冲到 1w+）。
3. 3. 再补阶段 5、6、8（release 配置）。
4. 4. 最后上阶段 7（内核参数）。

（全文完）