Fiber v3 性能实测解读：TechEmpower 基准测试下 Fiber 与 Express 的逐项对比

Fiber v3 性能实测解读：TechEmpower 基准测试下 Fiber 与 Express 的逐项对比

【免费下载链接】fiber⚡️ Express inspired web framework written in Go项目地址: https://gitcode.com/GitHub_Trending/fi/fiber

导读

Fiber 是一个受 Express 启发、构建在 FastHTTP 之上的 Go Web 框架，性能表现是其核心卖点。本文基于官方文档 docs/extra/benchmarks.md 中收录的 TechEmpower 基准测试结果，逐项拆解 Plaintext、JSON Serialization、Single Query、Multiple Queries、Data Updates 五项测试中 Fiber v3.0.0 与 Express 的吞吐量与延迟数据，并结合本仓库的源码设计（FastHTTP 引擎、零拷贝上下文、可插拔 JSON 编解码器等）解释这些数字背后的工程原理。读完本文，你将能正确解读这些基准数据的适用范围与限制，并学会在本地复现与测量 Fiber 的真实性能。

---

一、基准测试背景：TechEmpower 是什么

TechEmpower 提供对大量 Web 应用框架的性能对比评测，覆盖 JSON 序列化、数据库访问、服务端模板渲染等互联网服务中常见的基础任务。它的特点是：

• 每个框架都在接近真实的生产配置下运行；
• 结果同时在云端实例与物理硬件上记录；
• 测试实现由社区贡献并维护在 FrameworkBenchmarks 基准工程中，而非由某个框架官方自报成绩。

因此这是一份相对中立、可追溯的第三方对比数据，也是 Fiber 官方文档 docs/extra/benchmarks.md 引用的权威依据。Fiber 的 README.md 亦将 TechEmpower 的 Plaintext / JSON 测试结果图表直接展示在项目首页，作为其性能定位的公开证据。

二、测试环境与配置

官方文档记录的本轮测试运行环境如下：

项目	配置
被测框架	Fiberv3.0.0（对照：Express）
CPU	56 核 Intel(R) Xeon(R) Gold 6330 @ 2.00GHz（三台同构 ProLiant DL360 Gen10 Plus）
内存	64GB RAM
存储	企业级 SSD（Enterprise SSD）
操作系统	Ubuntu
网络	Mellanox Technologies MT28908 Family ConnectX-6 40Gbps 以太网

需要特别说明的一点是：这组数字对应的是 Fiberv3.0.0发布时的实测结果。本仓库当前源码中的版本常量已演进到3.5.0（见 app.go 中const Version = "3.5.0"）。也就是说，后续迭代对路由、绑定器（binder）、客户端等模块所做的改动并未反映在这份基准中；如果你在自己的机器上以最新版 Fiber 复测，数值可能略有出入，但这份数据仍可用于把握 Fiber 的量级定位。

三、五项测试逐项解读

3.1 Plaintext：纯路由与高吞吐压测

Plaintext 测试用于衡量基础请求路由能力，展示高性能平台的处理上限。请求采用管道化（pipelined）方式发送，而响应体极小，因此对吞吐量的要求极高——只有持续灌满基准测试的千兆以太网才能拿到好成绩。

指标	Fiber	Express
响应吞吐	11,987,976次/秒	1,204,969 次/秒
平均延迟	1.0ms	8.8 ms

这是最典型的"纯框架开销"测试：不涉及数据库、不涉及模板渲染，拼的就是请求解析、路由匹配与响应写入的原始速度。Fiber 在此以约10 倍吞吐、1/8 延迟的差距大幅领先，直接体现了其底层 HTTP 引擎的处理能力。

3.2 JSON Serialization：JSON 序列化性能

JSON 序列化测试测量框架在最短请求链路下输出 JSON 响应（通常不含数据库访问）的能力，是 CPU 密集、分配敏感的微基准。

指标	Fiber	Express
响应吞吐	2,363,294次/秒	949,717 次/秒
平均延迟	0.2ms	0.5 ms

Fiber 在此项同样接近 2.5 倍领先。序列化开销主要取决于编码器实现与缓冲区复用策略（详见下文源码分析）。

3.3 Single Query：单次数据库查询

从测试名可推断，此类任务在每次请求中执行单条数据库查询，将结果包装为 JSON 返回，用于衡量"路由 + 数据库驱动 + 序列化"的完整链路。

指标	Fiber	Express
响应吞吐	953,016次/秒	441,543 次/秒
平均延迟	0.6ms	1.3 ms

Fiber 在单查询场景下仍保持约 2.2 倍优势，说明一次数据库往返带来的开销尚未掩盖框架本身的性能差异。

3.4 Multiple Queries：多查询场景

Multiple Queries 在单次请求中执行多条数据库查询（名称即其含义），用于模拟聚合类数据接口的真实负载。

指标	Fiber	Express
响应吞吐	54,002 次/秒	85,011次/秒
平均延迟	9.4 ms	6.0ms

3.5 Data Updates：数据更新场景

Data Updates 属于数据库写入密集型测试（通过名称可推断为执行多条数据更新操作），同样是最接近 OLTP 写路径的一类任务。

指标	Fiber	Express
响应吞吐	29,984 次/秒	54,887次/秒
平均延迟	16.9 ms	9.2ms

3.6 结果概览与正确解读

将五项测试汇总如下：

测试	Fiber 吞吐	Fiber 延迟	Express 吞吐	Express 延迟	领先方
Plaintext	11,987,976 rps	1.0 ms	1,204,969 rps	8.8 ms	Fiber
JSON Serialization	2,363,294 rps	0.2 ms	949,717 rps	0.5 ms	Fiber
Single Query	953,016 rps	0.6 ms	441,543 rps	1.3 ms	Fiber
Multiple Queries	54,002 rps	9.4 ms	85,011 rps	6.0 ms	Express
Data Updates	29,984 rps	16.9 ms	54,887 rps	9.2 ms	Express

正确解读时需注意两点：

1. 测试性质决定了谁占优。Plaintext、JSON、Single Query 中框架自身的处理占比高，Fiber 依托 Go 原生并发与 FastHTTP 引擎优势明显；而 Multiple Queries、Data Updates 这类数据库密集测试中，总耗时被数据库往返与连接池行为主导，框架吞吐差距被大幅稀释，Express 在此反而取得更高数字。可见基准分数与工作负载特征强相关，不能简单概括为"Fiber 全面碾压 Express"。
2. 这两组测试各自只代表一类场景。如果业务是网关、短请求 API、高并发读，Plaintext/JSON/单查询结果更有参考价值；如果业务瓶颈在数据库，则应参考后两项，并结合你自己的数据库驱动与连接池配置做决策。

四、从仓库源码理解 Fiber 的性能设计

基准数字背后，是 Fiber 仓库中一系列可验证的工程决策。以下设计均能在本仓库源码与文档中找到依据。

4.1 基于 FastHTTP 构建：默认获得零依赖高性能 HTTP 引擎

Fiber 的 HTTP 引擎直接来自valyala/fasthttp。在 go.mod 中可以看到：

• github.com/valyala/fasthttp v1.73.0
• github.com/valyala/bytebufferpool v1.0.0

FastHTTP 通过对象池化、复用连接缓冲等手段显著降低每个请求的分配与系统调用开销；bytebufferpool则用于复用响应缓冲区。这正是 Fiber 在 Plaintext / JSON 这类高吞吐测试中能达到千万级 rps 的底层基础。README.md 对 Fiber 的定位描述即为"构建在 fasthttp（Go 最快的 HTTP 引擎）之上"，并明确以"为高性能与零内存分配而设计"作为目标。

4.2 零拷贝与Ctx池化：延迟与分配的取舍

Fiber 的另一项关键设计是上下文复用。README 的 Zero Allocation 一节明确说明：fiber.Ctx返回的值默认不可变（immutable）为假，会被跨请求复用；规则是只在 handler 内部使用这些值，绝不能持有引用跨 handler 存活。

• docs/guide/context.md 指出Ctx实例本身在请求结束后被池化复用，因此不要在请求外保存c或长期持有其值；
• docs/api/fiber.md 中的Immutable配置项可以一键切换：开启后所有上下文方法返回的值都会进行拷贝（不可变），代价是每次访问多一次复制。

这一"按需拷贝、默认零拷贝"的策略，使请求热路径上的内存分配趋近于零，直接降低了 GC 压力与尾部延迟；同时它也是 Plaintext 这类微响应用例得以满速运转的原因之一。若在 handler 之外继续引用零拷贝值，则会读到被后续请求覆写的数据，相关陷阱在 docs/extra/faq.md 中有专门的排查说明。

4.3 路由与处理器调用的紧凑实现

Fiber 的路由器集中实现在 router.go，并配有 router_skip.go 等路径优化模块，通过精简约简的匹配步骤把"路由命中 → 中间件链执行 → 响应写出"的控制流压缩到最短。配合按需分配的最小Ctx接口（见 ctx.go、ctx_interface.go），Fiber 在单次请求上避免了大对象的堆分配。

4.4 针对 JSON 与正则约束的可插拔加速

对于 JSON Serialization 这类测试，Fiber 允许替换内置的encoding/json。官方优化指南 docs/guide/faster-fiber.md 提供了在fiber.Config中注入JSONEncoder/JSONDecoder的写法，可替换为 goccy/go-json、bytedance/sonic、segmentio/encoding 等高性能实现：

package main import ( "github.com/gofiber/fiber/v3" "github.com/goccy/go-json" ) func main() { app := fiber.New(fiber.Config{ JSONEncoder: json.Marshal, JSONDecoder: json.Unmarshal, }) // ... }

同一文档还介绍了通过Config.RegexHandler替换路由regex()参数约束所用正则引擎（如改用 coregex）以加速带正则约束的路由匹配：

app := fiber.New(fiber.Config{ RegexHandler: coregex.MustCompile, }) app.Get("/api/:id<regex(\\d+)>", func(c fiber.Ctx) error { return c.SendString("ID: " + c.Params("id")) })

需要留意其注意事项：RegexHandler只影响regex()参数约束；编译后的匹配器在请求间被复用，因此自定义匹配器必须保证并发安全（详见 docs/guide/faster-fiber.md）。

4.5 版本与兼容性说明

由于 Fiber 使用了unsafe等底层手段以换取性能，其对 Go 版本的适配有一定前提。README 明确说明：Fiber v3 已针对 Go 1.25 及以上版本测试（go.mod 中go 1.25.0指令亦与之一致）。实测环境与被测框架版本务必与官方基准声明（Fiber v3.0.0）对齐，才能保证可比性。

五、如何亲自验证与复现

TechEmpower 基准的实现本身托管在社区维护的 FrameworkBenchmarks 工程中，任何框架的参赛实现都由社区贡献，Fiber 官方文档只收录其结果页数据，因此若要在完全相同的协议与管线条件下复测，应在其基准框架下运行。若只想在本仓库代码上做性能冒烟测试，可参考以下路径：

1. 搭建最小服务：参照 README.md 的 Quickstart 快速启动一个返回纯文本或 JSON 的 Fiber 应用：

package main import ( "log" "github.com/gofiber/fiber/v3" ) func main() { app := fiber.New() app.Get("/", func(c fiber.Ctx) error { return c.SendString("Hello, World 👋!") }) log.Fatal(app.Listen(":3000")) }

2. 压测与观测：本地起服务后，可使用常见的 HTTP 压测工具（如 wrk、hey、ab 等）观察吞吐与 P99 延迟，并在压测前后对比开启/关闭Immutable配置、替换 JSON 编解码器对结果的影响，从而直观验证上文 4.2、4.4 两节的设计取舍。

3. 运行仓库自带微基准：仓库 Makefile 提供了benchmark目标，执行 Go 标准微基准并输出内存分配统计：

make benchmark

其底层等价于go test ./... -benchmem -bench=. -run=^Benchmark_$。这类测试适用于对比 Fiber 内部函数（如路由匹配、上下文方法、消息打包等）的分配情况，但不能直接替代端到端的 HTTP 吞吐测试——两者结合才能得出更完整结论。

六、结论

综合 docs/extra/benchmarks.md 收录的 TechEmpower 数据与本仓库源码可得出如下要点：

• 在纯框架开销主导的 Plaintext、JSON Serialization、Single Query 三类测试中，Fiber v3.0.0 对 Express 取得 2.2 至约 10 倍的吞吐优势与更低的平均延迟；
• 在数据库密集的 Multiple Queries、Data Updates 测试中，Express 反而领先，说明框架吞吐差异会被数据库链路稀释，选择框架时应结合自身工作负载形态判断；
• Fiber 的性能并非魔法，而是来自 FastHTTP 引擎（go.mod）、零拷贝上下文与池化复用（docs/api/fiber.md 的Immutable、docs/guide/context.md）、紧凑路由实现（router.go）以及可插拔的 JSON / 正则加速（docs/guide/faster-fiber.md）等可验证设计；
• 任何基准数字都应结合版本（官方基准为 v3.0.0，当前仓库为 v3.5.0）、运行环境与测试类型综合解读，并在自己的目标负载下复测，才能得出可信结论。

如果你希望进一步调优 Fiber 单点性能，官方文档还提供了一份系统的 Faster Fiber 优化指南，可作为阅读本文后的下一步参考。

【免费下载链接】fiber⚡️ Express inspired web framework written in Go项目地址: https://gitcode.com/GitHub_Trending/fi/fiber