Go Http框架性能测评: Fiber vs. Gin vs. Go标准库

本内容是对知名性能评测博主 Anton Putra Fiber vs. Gin vs. Go (stdlib): Performance (Latency - Throughput - Saturation - Availability): Performance (Latency - Throughput - Saturation - Availability)内容的翻译与整理, 有适当删减, 相关内容和结论以原作地址为准

介绍

在本视频中,我们将对比 Fiber 和 Gin 这两个 HTTP 框架,以及 Golang 标准库 和 Go 1.22 版本新增的改进型多路复用器 。为了进行测试,我会将这些应用部署到 Kubernetes ,然后使用 Prometheus 监测 CPU 和 内存 的使用情况,并在 Grafana 中进行可视化展示。

我们还会对比 客户端延迟 以及每个框架所能处理的 每秒请求数(RPS) 。在这次测试中,我增加了外部客户端的数量,以产生足够的负载,从而迫使 Kubernetes 对这些应用进行调节。最终,我们会得出一个 明确的胜者。

为了运行此次测试,我在 AWS 上创建了一个 生产级 Kubernetes 集群 ,并使用了 m6a.4xlarge 实例类型。如果你想了解更多相关内容,我还有一门专门针对 EKS 初学者 的完整课程。


框架概述

在 Go 1.22 版本之前,仅使用 Go 标准库 来开发 REST API 是一项十分困难的任务。其主要原因之一是:标准库中的 HTTP 请求多路复用器(multiplexer)不支持将 URI 模式映射到 HTTP 方法 ,而这对于设计 RESTful 资源至关重要。因此,许多开发者最终选择了使用诸如 Gin 或 Fiber 之类的 第三方路由库。 (还有如Gorilla Mux,Chi)

但到了 Go 1.22 之后,其标准库已经足够强大,你 不再需要 额外的第三方 Web 框架来构建 REST API。当然,你仍然可以使用一些 外部中间件 来提高开发效率,但标准库 已经具备了所有必要的功能。


测试

现在,让我们开始部署这些应用到 Kubernetes ,并让它们在 空闲状态 下运行 10-15 分钟。

可以看到,Gin 框架 运行时的 内存和 CPU 占用略高 ,而 Go 标准库 的资源使用情况与 Fiber 相当接近。

正式测试

接下来,我将部署 20 个客户端 来为每个应用 生成流量 ,并逐步 增加请求量 。整个测试耗时 约 1.5 小时,在视频中将其压缩成数分钟,并在最后展示最终结果。

从测试流程来看,每 5 分钟 ,我们会 增加额外的 1000 RPS 负载 到每个应用。从一开始,我们就能观察到明显的趋势:

  • Gin 占用 更多的 CPU 和内存 ,并且 客户端延迟最高。
  • Go 标准库 的 资源占用接近 Fiber ,但其 延迟略高于 Fiber。
  • Fiber 的 CPU 和内存使用率最低 ,并且 延迟最低,在所有框架中表现最佳。

Fiber 基于 Fasthttp 框架 ,但很多人不喜欢它。Fasthttp 是一个 非标准的 HTTP 实现 ,它主要 专注于特定场景的高性能优化 。除非你 确实需要它的特定优势,并且了解相关风险 ,否则它 并不是一个推荐的默认选择 。甚至 官方文档 也建议 大多数情况下应使用标准的 http 库。


推至极限

让我们继续运行测试,直到所有应用 开始崩溃。

  • Gin 最先 达到了 Kubernetes 设定的 Pod 资源限制 ,导致 Kubernetes 开始对其进行调节(throttling) ,这直接 影响了性能,并增加了延迟 。如果你在 Kubernetes 中运行 CPU 密集型应用 ,一定要 监控throttling的情况。

  • 从 每秒请求数(RPS)图表 可以看到,Gin 在 2 个 CPU 和 256MB 内存的 Pod 限制 下,最多只能处理 15,000个请求。

  • 其次,Go 标准库 也开始 失败 ,并被 Kubernetes 限流,这导致其 延迟上升 。在同样的配置下,它最多能处理 17,000 RPS。
  • 最后,Fiber 也达到了极限,在约 20,000 RPS 时 开始退化。

测试结果分析

接下来,我们分别查看 整个测试期间的各项数据图表。

  1. 每秒请求数(RPS):展示了每个应用的最大吞吐量。
  2. 客户端延迟:测量了从客户端角度的响应时间。
  1. CPU 使用率:直观反映了每个框架的计算资源消耗情况。
  1. Kubernetes 限流(Throttling) :在理想状态下应为 0 秒 ,但由于我们将应用推至极限,Kubernetes 开始对它们进行 限流。
  1. 内存使用情况:展示了每个应用的内存消耗。

最终,Fiber 是本次测试毫无疑问的赢家 ,但它 并不适用于所有场景 。从我的个人观点来看,你可以 尝试在下一个 Go Web 或 REST 项目中使用标准库 ,因为它 已经具备所有必要的功能。


总结

如果你对 源代码 有任何改进建议,欢迎提交 Pull Request ,我一定会 审核并进行测试 。同时,也欢迎在 评论区 告诉我 你希望我测试哪些内容。

相关推荐
IT_陈寒1 小时前
SpringBoot启动慢得像蜗牛?原来是这个配置在捣鬼
前端·人工智能·后端
不才不才不不才3 小时前
Spring 源码系列(29): 20 道高频面试题源码级解析合集
java·后端·spring
索隆zoro3 小时前
Army 的可插拔架构:army-jdbc 与方言模块
java·后端
小蒜学长4 小时前
校园社团招新网站的设计与实现(代码+数据库+LW)
java·数据库·spring boot·后端·校园社团招新网站
蜗牛互联网5 小时前
从Barclays扩大Claude部署看受监管软件工程的责任重分配
java·大数据·人工智能·后端·软件工程
周杰伦fans6 小时前
C#对话摘要降低Token消耗
人工智能·后端·c#
做系统的大强7 小时前
脚本说 PASS、OS 读全零 —— 到底是谁在撒谎?
后端·操作系统
code2cat8 小时前
【随笔】MCP资源更新订阅:通知到达以后,Agent怎样刷新旧资料
java·后端·开发工具·ai agent·mcp
Harvil_9 小时前
任务跑一半,API 突然报“对话超长“断流:我给 Agent 修的紧急逃生通道
后端
用户EasyAdminBlazor9 小时前
EasyAdminBlazor SignalR 实时消息源码解析:从 NotificationHub 到站内消息
后端