有必要在海量长连接场景使用第三方网络库吗?

[Nazz]

环境是 go1.20, 测了一下 6w websocket 连接, 每 10s 收发一条消息, 我发现第三方网络库内存占用可能会低一些, 但是 CPU 占用率上没表现出优势. 使用 std net, 如果活跃连接不多, 即使有海量连接也不会明显提高 CPU 占用率.

[opengps]

自己使用标准库和直接采用第三方库，最大的差异在于经验，当你的经验和水平提高到一定程度，那么你就可以是一个稳定第三方库的输出者

[jones2000]

c++ 自己搞下呗， 端口复用， 连接数多了多 fork 几个进程处理， 连接数少了，就关几个进程。 最主要的还是提高单个请求的处理速度。

[Nazz]

@opengps 业务系统限流是必须的

[Nazz]

@jones2000 开发网关代理服务器这些基础设施才会考虑 cpp ，业务开发还是算了吧

[lysS]

@lesismal go 的 tls 以及那些套件都是标准库支持的，你弄过来有啥意义？

[lesismal]

@lysS
> go 的 tls 以及那些套件都是标准库支持的，你弄过来有啥意义？

哦。

因为：
1. 标准库的 tls 只支持同步读的解析，这意味着，需要单独一个协成处理读
2. 不只是标准库的 tls ，从 net.TCPConn 到 net/http ，都是同步读的解析，都需要单独一个协成
3. 海量连接的场景，每个连接一个协程对硬件消耗太多了，单个节点协程多了以后，内存、调度、GC & STW 都对进程的健康度不够友好，对企业成本、能源消耗和环保也都不友好
4. 我搞 nbio 是为了解决 3 的问题，解决 3 的问题，就要避免每个连接一个协程的方案，回归其他传统语言的异步方案。虽然 go 底层也是异步 io ，但是如 1/2 所述，标准库提供给用户的同步接口导致海量连接数场景下协程爆炸问题。所以实际上是要做 event driven+async io+nonblocking user interface 。所以 nbio.Conn 实现了异步的 net.Conn ，也实现了异步流解析的 http parser ，也魔改了标准库 tls 实现了异步流解析的 tls

大多数人都会说，实际业务没那么大连接数，即使多一些，堆机器也足够了。
可能大家业务不一样吧，我处理的业务量相对而言，稍微多一点，能省不少，而且也有些老外在用我的库去做类似的事情。通常大中厂的业务量，用我的这个，相比于标准库，都能节省不少资源。
不知道这算不算有意义

[lesismal]

@Nazz
#9 的结论不太对。我上次测试，是用纯 c 对比 go 里用 cgo 调 c ，纯 c 确实快很多。但是实际应该是对比纯 go 和 cgo 。搜了下刚好有其他人做了 openssl 的 cgo wrap ，他的 benchmark 数据好于纯 go 。。。
所以应该还是有的搞

[lesismal]

@lesismal #27
应该是要考虑阈值的问题：
如果 c 的功能比较复杂、c 开销+cgo 的开销大于纯 go 实现的开销，就没必要。比如一个简单的 sum(a, b)，妥妥的纯 go 划算。否则 cgo 搞，还是有提升空间。

[Nazz]

@lesismal 跑 https 压测 cgo 比纯 go 快多少？

[lesismal]

@Nazz 还没试过，尝试这个要改造的工作量也不小