看样子好多人的迷惑都是类似的：
https://www.reddit.com/r/golang/comments/13wfae2/gowebsocketbenchmark_including_nbio/

@ruanimal @lysS #18 回复忘记 at 了，请查看 #18

> 好奇什么业务会用到百万链接，看测试 echo 都 500ms 以上了
> 这么大的连接，几乎做不了重的任务，一般都是简单的 ping-pong ；比如说广告计数、上线通知之类的

低配硬件：高在线、低频的功能，比如推送业务
高配硬件：高在线、高频的也可以做。主帖已经说明过了，测试用的 4C-2G "只是作为一个参考指标，用不是特别高的配置更能体现框架的承载力"，实际业务可以根据业务需要来部署硬件规格


> 话说怎么测的？ 100w 连接端口不够吧？而且 loopback 肯定有优化的

套接口对四元组包括：server ip, server port, client ip, client port ； port 是 short int 2 字节 64k ，加上系统 port range 配置项这些限制，这四元组在 server ip 、client ip 各只有 1 个的情况下，每个 server port 可以建立小于 64k 个连接，N 个 server port 可以建立 64k*N 个连接。测试为了省去虚拟网络或者 docker 方式的麻烦、使用了 50 个端口：
https://github.com/lesismal/go-websocket-benchmark/blob/main/config/config.go#L27

@blankmiss

帖子前置条件里我也说了，绝大多数人没这个扣内存的需求，但是确实也有少量比例的团队需要去扣这里，因为这部分人面临的在线量很大，扣这个能省的成本、对服务稳定性的提高也是很客观的

早几年 uber 就对海量并发各种 手动 gc 优化，甚至去改 go 源码。但其实如果用 nbio ，可能比他们的这些方式更有效一些

> 可能现在硬件条件已经很好，动态扩容，不是非常需要说对内存扣扣省省

动态扩容确实能解决一些问题，但成本也是不小，我知道的一些团队的一些服务，用的 java ，上百个云节点，而且这种公司还不是头部企业的业务量级。如果改成 nbio 这种，往多了说能省 95% 的成本，往少了说，也能省 80%

nbio 关注的用户里，估计大概三分之一是外国人吧，早期就有外国人是来用 nbio 处理高在线量的业务的

联排桌子抖腿才是大杀器
大家一起抖腿才是欢乐多

打不过就加入，你会发现工作变得有趣了

说好的男生永远专一永远喜欢 18-25 岁的女生呢

程序员太老实，老实人太容易被坑。支持 OP 刚它们！

@blankmiss 欢迎来杠。

我想问一下，那 c/cpp 也都性能杠杠的，为啥还搞 rust ?
rust 解决 c/cpp 的安全问题

为啥 go 成为并发、云各种场景下的宠儿？因为它除了性能还不错，更重要的是开发效率高。

java 开发效率高，但是它对于性能场景和硬件消耗实在太不堪入目了，所以 go 替换 java 可以实现节能环保，并且开发效率也高。
别给我杠说什么 java 开发功能快，java 发展了多少年积累了多少轮子？而且很多说 go 开发效率低的真的熟悉 go 吗？而且时间久了 go 的轮子也越来越多越来越完善。如果为了当下谁轮子最多就用谁，那性能、占用之类的各种问题永远没法优化，甚至 java 社区自己都不需要进化、因为现在已经能做功能只是消耗高一些罢了。

你用 rust 更节能环保，你有 go 的这种开发效率吗？再说句不好听的，100 个人学 rust ，有几个能短时间玩熟练的？
c/cpp 三年不出门，go 三天 curd ，你 rust 学多久能快速开发？

> 唉...C1M 问题很久就有各种方案了（几乎是 10 年前），似乎重要的不是同时多少连接在线（一般只和内存大小相关），而是保持大链接下的高 QPS （调度能力），个人经验 4c 配置 QPS 很容易到达 30w 左右的（小报文）

@wslzy007

epoll 异步非阻塞早就解决 C1M 了，这没错，c/cpp 里也早就不是问题了。

但这个帖子说的不是 c/cpp/rust 或者 java netty 或者其他脚本语言那些基于 c/cpp 这些底层，而是 go ，搞 go 的 poller 目的是解决 go 标准库方案每个连接一个协程导致的内存爆炸 OOM 、GC 负担过重 STW 的问题，主要是针对 go 自己，而不是说用 go 解决了其他语言解决不了的 C1M 问题。

@byte10
嗯嗯，欢迎多来交流，java 只是社区积累的框架多，但性能相关的实在是太不友好了

平时少把 java 搞，内存杀手不环保
重心多往 golang 转，护发节能走得远

@buffzty 66666

@byte10
但如果想基于 poller 4 层 TCP 去自己实现 7 层框架比如 HTTP/Websocket ，那没什么好办法了，还是需要异步。但 nbio 提供的 http/websocket 并不需要用户全去写异步！不需要！不需要！不需要！我都给你说了好多次了而且这个帖子里也写了 “以前很多次遇到很多人先入为主地以为异步框架就是要写回调、golang 框架也如此。 为了避免误解”

你先看明白了，别再回复我说要异步了！
我快成复读机了快被你们逼疯了！！！
😇😇😇😇😇😇😇😇

@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

> 可，评论区的一些评论我实在看不懂～

你可能还不知道吧，以前只是站着说话不腰疼，现在是躺着说话他也不腰疼呐

@fds #26 windows 只为方便开发。。打死我也不会去支持 iocp 了，哈哈哈，太难搞了

@fds
> 标准库不可能接受这种异步的实现方式。go 标准都是用同步写逻辑的。

标准库底层是非阻塞 io ，net.Conn 给用户提供阻塞接口 Read/Write ，用户需要主动 Read
nbio 底层也是非阻塞 io ，nbio 的 http/websocket nonblocking 模式下给用户提供的是非阻塞接口 Write ，用户不需要主动 Read 。nbio 基本兼容标准库，用户基于 nbio 可以像写标准库 http 一样，少量不兼容比如涉及 io.Copy ，其他的普通功能，只要把 io 替换成 nbio 就可以了、业务代码都不需要改，gin/echo 之类的也都能轻松用 nbio 替换 std http server 。
代码看下就能用了：
https://github.com/lesismal/nbio-examples/blob/master/http/server/server.go
https://github.com/lesismal/nbio-examples/blob/master/http_with_other_frameworks/gin_server/gin_server.go

> op 不要灰心，大部分不需要连上万客户端的场景确实没必要这样优化，但我确实遇到过需要的情况。我当时是先试了 > https://github.com/panjf2000/gnet 后来用的是 https://github.com/xtaci/gaio 但结果跑了一个月遇到了一次死锁，> 运维直接重启了，也没日志，公司当时还有别的事要忙，就没继续改进。

来吧，用 nbio ，还有救：
https://github.com/lesismal/nbio

这里有百万连接 websocket 的：
https://github.com/lesismal/go-websocket-benchmark

> 3202 年是不是可以用上 io uring 了（

@codehz 单就网络 io 这块，不同场景下 io uring 、epoll 性能好像是各有优劣，并不是所有情况都一边倒，所以综合网络库 epoll 有历史加持、足够了。特定场景的话倒是可以考虑定向优化

> 2023 年还在写回调，无异于开历史倒车

@z3phyr
试试我这个，http 基本兼容标准库，http 和 websocket 来消息时都是可以写同步代码的。
https://github.com/lesismal/nbio

支持 OP 一下！