> nbio VS gnet

@qbmiller

对于七层协议：gnet 不支持 TLS/HTTP/Websocket ，gnet examples 对这些 7 层协议相关的示例似乎并不是完整功能，离实用还差很多，gnet 的 README 里所说的 HTTP 性能并不是真正的完整功能 HTTP 框架，当初那个只是简单地解析 HTTP 换行符之类的这种，所以用于跟别人完整功能的 HTTP 框架对比性能本身就是不合理的。有给 gnet 作者聊过这个问题，他解释了原因：
https://github.com/panjf2000/gnet/issues/182
好像有其他人在 gnet 之上封装过 TLS ，但易用性相比于 nbio 应该还差很多吧，结合实际场景的应用不知道效果如何。

对于四层：我也有做测试： https://github.com/lesismal/go-net-benchmark/issues/1
nbio 的 used by 列表里有 gnet-io/gnet-benchmarks 但现在的 gnet-io/gnet-benchmarks 好像是没有包含 nbio ，可能是测过之后删掉了吧：
https://github.com/lesismal/nbio/network/dependents?dependents_after=MjQ3MjQyNjExMzI

根据我自己压测的情况是，单就四层而言，nbio 和 gnet 性能差不多，跑多轮测试有时候 nbio 高一点有时候 gnet 高一点，我的环境里跑 10 轮，可能 nbio 有 7 、8 次会略高一些。

因为遇到过多次如下情况：benchmark 库官方提供的压测数据与我自己实际跑他们官方测试代码的数据差异较大，也包括一些类似 gnet HTTP 性能这种压测数据不符合实际场景的情况。
所以我通常不建议直接以压测仓库作者提供的压测数据作为参考依据，包括我自己写的压测代码。所以我建议有兴趣的兄弟姐妹还是自己跑下实际代码试试看，并且也可以根据实际测试参数、尽量把各个框架的参数、配置对齐来公平对比而不是被作者自己号称的性能忽悠。

越是挣扎，越是真的要没落了。

怎么着，这年头伸手党都这么犀利了吗？又不是什么复杂的难题，要是说“请教下怎么实现”那都绝对不算是伸手党。可这连标题都是下需求，OP 头像脸都不要了也就算了，咋请教个问题也脸都不要了呢。。

是因为经济不景气、所以楼上各位就这么卷着来伺候伸手党吗？建议不要吧

早上起床气还没有散，加上是 go 的，希望 gopher 至少能动动脑子，所以对不住了各位，请收了神通吧！

塔尖以下共同富裕
中产失业拿出积蓄
人口太少鼓励生育
回到原形家徒四壁

你们这些年轻人啊，这样下去是要亡国灭种的！这样的态度要不得！
再这样下去，就只能修改计划生育政策内容了，把以前的的”旧计划”改成“新计划”：
以前不让多生，以后强制多生！以前给你们发免费的套套和避孕药以及上其他配套手段，以后免费发维生素片、壮阳催情药！妇联的大姐和阿姨们每天下班去你家里催你们圆房！按照年龄段、身体素质综合情况为每家指定频率，排好家访的 schedule ，每天去今日需要交任务的家庭、隔着门听你们完成今天的业务后在小本本上记录下来才肯离开！

@jimages
以前对陈皓不熟悉，他去世了才去看了他的主页，看到那几个抵制资本家之类的观点，觉得他人很好。但偶尔看到他的一些技术观点，我不认同。

比如只喜欢 go 的小伙子不该被技术限制这个故事：
1. 很多老手都有同样的观点，技术只是工具。但一个年轻人在技术积累期间，深挖一个方向是很有必要的，钻研一下精深一些，积累到实例之后再去扩展技能点，能让自己做到博而精，而且多数人经历几年钻研后也基本都会自己体会到技术只是工具，根本不需要年长者们提前来指导。这种指导，更多概率是造成这些年轻人博而不精，都成了 CURD 工具人。所以其实是两个不同阶段的人，年长者的建议初衷是好的、效果可能是差的。我身边就有这种例子，大专肄业的小伙子，刚工作技术很菜，拿着不够生活费的低工资只为求学习转行的机会，然后坚持了几年硬啃 c++、数据库相关的领域，现在是他们公司开发里的大拿，代码能力超过很多他的名校专业硕士同事。他几年前也是在各种技术群里问各种问题，很多老手给他说技术只是工具，幸亏他自己有坚持，没有盲从那些建议。就像罗永浩说的，不是每只鸟来到世上都是为了躲枪子的。
2. 虽然语言只是工具。但不同语言解决问题的能力，确实大不相同。最简单的方法，整体思维，如果学什么语言不重要，那也就意味着随便哪个语言都可以解决所有问题了，然而并不是，所以才会有 go 、rust 的再次横空出世并且大火。

直接看标准库源码，或者找个代码比较好的 repo ，结合 repo 看标准库源码，比看书强多了

提示：
国产鳗鱼：国内生产的添加剂导致问题的带包装鳗鱼
日本鳗鱼：从中国进口的无包装鳗鱼

2022 Go 生态圈 rpc 框架 Benchmark
https://colobu.com/2022/07/31/2022-rpc-frameworks-benchmarks/

https://github.com/lesismal/arpc

看样子好多人的迷惑都是类似的：
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 问题。