http、fasthttp与netpoll方案

[lesismal]

看到tony老板这篇文章：https://tonybai.com/2021/04/25/server-side-performance-nethttp-vs-fasthttp/

那么，在持续“饱和”请求的场景下，如何让fasthttp workerpool中goroutine的数量不会因conn的增多而线性增长呢？fasthttp官方没有给出答案，但一条可以考虑的路径是使用os的多路复用(linux上的实现为epoll)，即go runtime netpoll使用的那套机制。在多路复用的机制下，这样可以让每个workerpool中的goroutine处理同时处理多个连接，这样我们可以根据业务规模选择workerpool池的大小，而不是像目前这样几乎是任意增长goroutine的数量。当然，在用户层面引入epoll也可能会带来系统调用占比的增多以及响应延迟增大等问题。至于该路径是否可行，还是要看具体实现和测试结果。

关于netpoll tls/http/webwocket 的方案

我这有个repo，主要解决golang单进程1000k问题。普通并发量的简单echo压测场景响应性能未必比标准库强，但海量并发要强很多：
https://github.com/lesismal/nbio

一些简介：https://www.v2ex.com/t/794435

http 基本兼容标准库：
https://github.com/lesismal/nbio_with_other_frameworks

只作为网络库的性能与同类repo比较：
https://github.com/lesismal/go-net-benchmark
lesismal/go-net-benchmark#1

另外，易用性远高于同类repo

[bigwhite]

好的，感谢提供思路与方案👍。