4C-2G 来战 [ Golang Websocket 百万连接测试 ]

代码代码： https://github.com/lesismal/go-websocket-benchmark

使用框架： https://github.com/lesismal/nbio

总结：4cpu 核心，2G 内存，100 万连接，1k 数据载荷，500 万次 Echo 测试，TPS 10+万，详情请继续往下看。

看到隔壁帖子一些人上来就说这没用那没用 https://www.v2ex.com/t/945616

想起之前自己帖子也是类似： https://www.v2ex.com/t/755862

之前几次也是被好些人说 nbio 这没用那没用，所以有感而发。

PS：期待 @byte10 大神百忙之中能再来与我讨论技术。

前置声明：

绝大多数人不需要百万级连接场景的优化，但确实有公司有项目有人需要，搞这些东西就是为了满足这些需要；
标题 4C-2G 只是作为一个参考指标，用不是特别高的配置更能体现框架的承载力。采用这个配置并不是鼓励实际场景就要用这么低的配置去处理百万连接，实际场景应从实际出发；
否定别人只需要动动嘴，但技术是实在的，如果也有兄弟姐妹想说 nbio 之类的 poller 没用，请确认自己真正了解相关知识，然后带上实际的论据观点再来讨论，如果实在想这么讲，也请先看下旧帖。

以前很多次遇到很多人先入为主地以为异步框架就是要写回调、golang 框架也如此。为了避免误解，这里也再对 nbio 的同步异步做下简要说明： nbio 底层非阻塞、异步 io ，但使用逻辑协程池处理 http 请求、websocket 消息，由于 golang 协程不像进程线程成本那么高，所以逻辑协程池 size 比 c/cpp 或者其他语言的逻辑线程数量大得多，所以用户仍然可以写同步逻辑，实际上也是这样处理的。

为了避免既当裁判又当运动员、甚至误导用户，每当有人问我性能时，我通常是建议用户以自己实测得到的性能数据为准，而不是直接相信测试库作者提供的数据。所以建议有兴趣的兄弟姐妹在自己环境进行测试。

如果测试库代码有误，欢迎 Issue/PR 来指正更正。

在这里也邀请并欢迎大家来跑下多个 go websocket 框架的测试，并留言到这里供参考： https://github.com/lesismal/go-websocket-benchmark/issues/11

另外：除了 nbio 以外的其他 go websocket 框架多数主要是基于 golang 标准库、每个连接一个协程，这种普通配置的硬件上无法跑到海量连接，所以百万连接测试的脚本默认只针对 nbio 自己，如果想测试更多参数，请自行修改脚本。 gev 支持百万但不支持 TLS ，gobwas+netpoll 有 for loop 阻塞问题，所以目前没有添加它们，以后可能会添加。

下面是我的 ubuntu vm 上跑的数据，仅供参考

环境：

--------------------------------------------------------------
os:

Ubuntu 20.04.6 LTS \n \l

--------------------------------------------------------------
cpu model:

model name	: AMD Ryzen 7 5800H with Radeon Graphics
--------------------------------------------------------------
              total        used        free      shared  buff/cache   available
Mem:       16362568      396988    15151676        1636      813904    15656380
Swap:             0           0           0
--------------------------------------------------------------
# taskset 0-3, nbio server 只占 4 cpu 核心
run nbio_nonblocking server on cpu 0-3
--------------------------------------------------------------

压测结果：

--------------------------------------------------------------
BenchType  : Connections
Framework  : nbio_nonblocking
TPS        : 26545    # 每秒建立连接数
Min        : 20ns     # 建立单个连接最小耗时
Avg        : 74.80ms  # 建立单个连接平均耗时
Max        : 37.67s   # 建立单个连接最大耗时（实际压测并发度大，有一些容易失败，目前测试逻辑会重试、多次重试时间导致最大值时间较长）
TP50       : 30ns     # 前 50%次建立连接最大耗时
TP75       : 30ns     # 前 75%次建立连接最大耗时
TP90       : 30ns     # 前 90%次建立连接最大耗时
TP95       : 30ns     # 前 95%次建立连接最大耗时
TP99       : 31ns     # 前 99%次建立连接最大耗时
Used       : 37.67s   # 总耗时
Total      : 1000000  # 建立连接数
Success    : 1000000  # 成功建立连接数
Failed     : 0        # 建立连接成功数（实际压测并发度大，有一些容易失败，目前测试逻辑会重试、多次重试都失败才算失败）
Concurrency: 2000     # 并发度（ 2000 个协程，每个协程循环建立连接）
--------------------------------------------------------------
BenchType  : BenchEcho
Framework  : nbio_nonblocking
TPS        : 113789     # 每秒 Echo 次数
Min        : 182.56us   # 单次 Echo 最小耗时
Avg        : 435.80ms   # 单次 Echo 平均耗时
Max        : 1.69s      # 单次 Echo 最大耗时
TP50       : 407.61ms   # 前 50%次 Echo 最大耗时
TP75       : 554.56ms   # 前 75%次 Echo 最大耗时
TP90       : 698.06ms   # 前 90%次 Echo 最大耗时
TP95       : 800.52ms   # 前 95%次 Echo 最大耗时
TP99       : 1.07s      # 前 99%次 Echo 最大耗时
Used       : 43.94s     # 总耗时
Total      : 5000000    # 测试 Echo 次数
Success    : 5000000    # 测试 Echo 的成功次数
Failed     : 0          # 测试 Echo 的失败次数
Conns      : 1000000    # 测试的连接数
Concurrency: 50000      # 并发度（ 5w 个协程，每个协程循环取当前可用的连接进行 Echo ）
Payload    : 1024       # websocket body size
CPU Min    : 95.96%     # CPU 最小值（采集开始时较小）
CPU Avg    : 347.80%    # CPU 平均值
CPU Max    : 380.94%    # CPU 最大值
MEM Min    : 1.82G      # MEM 最小值（ Benchmark 开始前有进行 Warmup ，所以起始内存最低值已经较大）
MEM Avg    : 1.92G      # MEM 平均值
MEM Max    : 1.94G      # MEM 最大值
---------------------------------------------------------------------------------------------------

lesismal

2023-06-05 11:13:57 +08:00

@byte10 之前好多次没回复我，还以为你把我 block 了 :joy: ，感谢回复！

> 但还是保持一些观点，如果放在业务层去使用，大部分开发人员还是会用协程去写同步代码，那么就跟你省内存的初衷违背了。

其实你还是误解了，我解释过好多次了，框架本身是提供了逻辑协程池的，用户仍然是同步代码，比如 http handler ，这个跟使用标准库写同步代码没什么区别:
https://github.com/lesismal/nbio-examples/blob/master/http/server/server.go#L19

nbio 里，每个 http 请求到来时取一个协程处理，这个请求处理完了这个协程可以继续服务其他请求，并不是每个连接固定、持续占用一个协程。

c/cpp 那些框架，线程太贵，所以线程池数量少，很多框架是逻辑单线程，所以需要各种回调。
但 golang 协程不一样，协程便宜，百万链接那是协程数量太大了，但是 1-10w 协程压力不大，所以逻辑协程池 size 弄个几千几万个协程是可以的。而且 golang 其他的 io ，比如到数据库，也是有连接池限制的。即使 100w 个逻辑协程也是可能被数据库连接池卡着等待，所以太大逻辑协程数量也意义不大，反倒是几千几万这种协程池数量，已经足够动态均衡了。

总结下就是，逻辑协程数量多但是可配置、不好过硬件能力：
1. 如果是快业务，每次请求处理很快、协程能很快释放给其他请求去复用
2. 如果是慢业务，逻辑协程再多也是要被阻塞，但逻辑协程数量通常远多余下游（比如数据库）的限制，所以仍有足够的空闲协程处理其他请求

所以对于通用需求，根本不存在你先入为主地以为的那种用了 nbio 就要写回调的问题。

而有一些需求，即使是用标准库，也可能是需要写回调的。特殊问题，特殊处理就可以了。

比较均衡的并发模式是：
1. 纵向的不同分层上（比如网络库、框架、业务层），各层限制好自己的资源使用，比如协程池、buffer pool
2. 横向的不同模块上（比如 A 功能 B 功能 C 功能），各模块限制好自己的资源使用，比如协程池、buffer pool

架构是灵活的，人也应该灵活，欢迎来试试 nbio