go 和 rust 是龙兄虎弟左邻右李伯牙子期，不要把他俩对立，而是双剑合璧干死其他静态类型语言：
1. 用 go 处理性能不是最敏感但是性能和开发效率都很重要的很多偏应用业务比如 CURD 、以及少量系统编程业务比如云原生
2. 用 rust 去搞安全要求高的性能要求强的去干掉 c/cpp 为主，干掉其他为辅

应该一起喜欢这两个

@doanything 赶巧了，我也是前几天看到别人收藏里有这个，就也收藏上了😄

这里找找看：github.com/iGaoWei/BigDataView

> 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 岁的女生呢