[开源] rload: 仅 3.5MB 内存，原生支持 Nginx 日志回放的 Rust 高性能压测工具
# [开源] rload - 仅 3.5MB 内存，原生支持 Nginx 日志/JSONL 回放的 Rust 高性能压测工具（ wrk 兼容）
各位 V 友，大家好！
平时在做后端开发、架构设计或 SRE 运维时，大家肯定都用过 `wrk`。它的单机吞吐量和极低的内存占用（常驻 3MB 左右）绝对是业界的标杆。
但在实际生产中，我们经常遇到一个头疼的问题：**“静态单接口压测看起来稳如老狗，线上真实复杂流量一进来，数据库/缓存就瞬间雪崩。”** 想要高保真地还原线上故障、做靠谱的容量规划，最直接有效的办法就是——**直接回放真实的线上 Nginx 访问日志（ access log ）**。
然而，现有工具在这点上都不太完美：
1. **wrk**：原生不支持日志回放，必须写 Lua 脚本，维护成本高，调试困难。
2. **k6**：虽然支持 JS 脚本，但内置的 JS 运行时和 GC 导致单机压测极其消耗 CPU 和内存（随随便便几百 MB ），压测数据也容易因 GC 发生抖动失真。
3. **Locust**：Python 协程性能偏低，单机几千 RPS 就满载了，回放几十万日志得拉一整个容器集群，成本高昂。
为了解决这个痛点，我用 Rust 编写了 **`rload`**，并已经在 GitHub 开源。
- **GitHub 仓库**： [https://github.com/wenhaozhao/rload](https://github.com/wenhaozhao/rload)
- **项目官网**： [https://wenhaozhao.github.io/rload/](https://wenhaozhao.github.io/rload/)
---
### 🚀 免安装，一键直接运行！
为了让大家用得爽，**目前我们已经在 GitHub Releases 页面发布了全平台的预编译静态二进制包**！
无需配置 Rust 编译环境，支持一键直接运行：
- **macOS** (Apple Silicon M1/M2/M3 & Intel)
- **Linux** (x86_64 & AArch64 架构，无 glibc 版本依赖限制)
- **Windows** (x86_64, 原生适配 PowerShell 与套接字恢复)
> 💡 **快速上手：**
1. 去 Releases 页面下载对应系统的压缩包解压。
2. 从线上服务器导出一份 `access.log` 到本地。
3. 运行命令，直接以 100 并发顺序/随机回放真实流量：
`rload -c 100 -d 30s --log-replay access.log http://staging-env.internal`
---
### 🛡️ 核心亮点：
- 🚀 **与 wrk 性能与指标对齐（基于 mio ）**：
我们故意没有选择高层的 async await runtime （如 Tokio ），而是直接基于裸 **`mio`**（非阻塞 I/O 复用）实现了高效的工作线程绑核模型。
在 macOS / Linux 上与 wrk 进行的配对运行基准测试表明：吞吐量（ RPS ）平均绝对误差（ MAE ）仅为 **0.986%**，P50/P90 延迟误差控制在 1% 左右，内存常驻仅为 **3.55 MiB**，完美对齐 wrk ！
- 📂 **原生支持 Nginx 日志回放**：
直接读取 Common 或 Combined 格式的 Nginx 访问日志，支持 **顺序、洗牌（ shuffle ）和随机** 三种回放模式。支持传入种子（`--seed`），确保每次洗牌后的请求序列在无数次运行中完全一致，保障测试的可重复性（ A/B Test 对比）。
- 📝 **原生支持 JSONL 请求回放**：
如果需要压测复杂的 POST/PUT 请求，直接将请求方法、Header 、Body 导出为标准的 JSONL 格式，rload 即可原生高并发回放，再也不用痛苦地去写 Lua 脚本了。
- ⏳ **多种流量控制步调（ Pacing ）与协同遗漏预防**：
支持固定全局速率、基于时间戳的速度步调（ timestamp-speed pacing ）以及定时速率阶段切换。通过高精度时间轮排程，精准预防传统压测工具中普遍存在的 **Coordinated Omission （协同遗漏）** 统计误差。
---
### 严谨的准确性判定：
我们在仓库里的 `benchmarks/[VALIDATION_2026-07-11.md](http://validation_2026-07-11.md/)` 极其详细地记录了我们的准确性判定方法、配对运行的原始数据以及门槛限制。我们甚至主动写出了我们在“零延迟回环 P99 略微超过 5% 判定门槛”这一局限性，绝不夸大宣传，欢迎各位硬核大佬来拍砖和 Code Review ！
如果您对高性能网络 I/O 编程、Rust 裸 mio 实现感兴趣，或者正好在线上遇到复杂的日志回放压测需求，欢迎体验并给个 Star ⭐️ 支持！
期待各位 V 友的反馈、Issue 或 Pull Request ，任何吐槽或想法我都非常欢迎和感激！
---
原文链接：[点击查看](https://www.v2ex.com/t/1230682)
各位 V 友，大家好！
平时在做后端开发、架构设计或 SRE 运维时，大家肯定都用过 `wrk`。它的单机吞吐量和极低的内存占用（常驻 3MB 左右）绝对是业界的标杆。
但在实际生产中，我们经常遇到一个头疼的问题：**“静态单接口压测看起来稳如老狗，线上真实复杂流量一进来，数据库/缓存就瞬间雪崩。”** 想要高保真地还原线上故障、做靠谱的容量规划，最直接有效的办法就是——**直接回放真实的线上 Nginx 访问日志（ access log ）**。
然而，现有工具在这点上都不太完美：
1. **wrk**：原生不支持日志回放，必须写 Lua 脚本，维护成本高，调试困难。
2. **k6**：虽然支持 JS 脚本，但内置的 JS 运行时和 GC 导致单机压测极其消耗 CPU 和内存（随随便便几百 MB ），压测数据也容易因 GC 发生抖动失真。
3. **Locust**：Python 协程性能偏低，单机几千 RPS 就满载了，回放几十万日志得拉一整个容器集群，成本高昂。
为了解决这个痛点，我用 Rust 编写了 **`rload`**，并已经在 GitHub 开源。
- **GitHub 仓库**： [https://github.com/wenhaozhao/rload](https://github.com/wenhaozhao/rload)
- **项目官网**： [https://wenhaozhao.github.io/rload/](https://wenhaozhao.github.io/rload/)
---
### 🚀 免安装，一键直接运行！
为了让大家用得爽，**目前我们已经在 GitHub Releases 页面发布了全平台的预编译静态二进制包**！
无需配置 Rust 编译环境，支持一键直接运行：
- **macOS** (Apple Silicon M1/M2/M3 & Intel)
- **Linux** (x86_64 & AArch64 架构，无 glibc 版本依赖限制)
- **Windows** (x86_64, 原生适配 PowerShell 与套接字恢复)
> 💡 **快速上手：**
1. 去 Releases 页面下载对应系统的压缩包解压。
2. 从线上服务器导出一份 `access.log` 到本地。
3. 运行命令，直接以 100 并发顺序/随机回放真实流量：
`rload -c 100 -d 30s --log-replay access.log http://staging-env.internal`
---
### 🛡️ 核心亮点：
- 🚀 **与 wrk 性能与指标对齐（基于 mio ）**：
我们故意没有选择高层的 async await runtime （如 Tokio ），而是直接基于裸 **`mio`**（非阻塞 I/O 复用）实现了高效的工作线程绑核模型。
在 macOS / Linux 上与 wrk 进行的配对运行基准测试表明：吞吐量（ RPS ）平均绝对误差（ MAE ）仅为 **0.986%**，P50/P90 延迟误差控制在 1% 左右，内存常驻仅为 **3.55 MiB**，完美对齐 wrk ！
- 📂 **原生支持 Nginx 日志回放**：
直接读取 Common 或 Combined 格式的 Nginx 访问日志，支持 **顺序、洗牌（ shuffle ）和随机** 三种回放模式。支持传入种子（`--seed`），确保每次洗牌后的请求序列在无数次运行中完全一致，保障测试的可重复性（ A/B Test 对比）。
- 📝 **原生支持 JSONL 请求回放**：
如果需要压测复杂的 POST/PUT 请求，直接将请求方法、Header 、Body 导出为标准的 JSONL 格式，rload 即可原生高并发回放，再也不用痛苦地去写 Lua 脚本了。
- ⏳ **多种流量控制步调（ Pacing ）与协同遗漏预防**：
支持固定全局速率、基于时间戳的速度步调（ timestamp-speed pacing ）以及定时速率阶段切换。通过高精度时间轮排程，精准预防传统压测工具中普遍存在的 **Coordinated Omission （协同遗漏）** 统计误差。
---
### 严谨的准确性判定：
我们在仓库里的 `benchmarks/[VALIDATION_2026-07-11.md](http://validation_2026-07-11.md/)` 极其详细地记录了我们的准确性判定方法、配对运行的原始数据以及门槛限制。我们甚至主动写出了我们在“零延迟回环 P99 略微超过 5% 判定门槛”这一局限性，绝不夸大宣传，欢迎各位硬核大佬来拍砖和 Code Review ！
如果您对高性能网络 I/O 编程、Rust 裸 mio 实现感兴趣，或者正好在线上遇到复杂的日志回放压测需求，欢迎体验并给个 Star ⭐️ 支持！
期待各位 V 友的反馈、Issue 或 Pull Request ，任何吐槽或想法我都非常欢迎和感激！
---
原文链接：[点击查看](https://www.v2ex.com/t/1230682)
评论
暂无评论。