等了几个月终于有动静了：
https://github.com/TechEmpower/FrameworkBenchmarks/issues/9916
顺便给 gnet 也提了个 issue 建议移除之前天梯跑第一的误导性测试结果： https://github.com/panjf2000/gnet/issues/733
原文：
建议移除 FrameworkBenchmarks 测试结果，避免造成误导 gnet 性能超强的观点已经在小白中持续了好些年，但这是误导性的，FrameworkBenchmarks 官方已经对非完整 HTTP 协议支持的框架做了” Stripped/剥离“的分类： TechEmpower/FrameworkBenchmarks#9916 即使是 TCP 测试，gnet 也不一定是最强的，而是第一梯队的框架性能其实差不多的。连接数、io 协程数等不同参数，跑多轮，nbio 比 gnet 强的次数还多一些，当然这可能是个人环境差异，用户应该以自家实际测试结果为准： lesismal/go-net-benchmark#1 nbio 支持 TLS/HTTP/Websocket ，但是从未在自称性能比其他框架强，因为对于普通连接数，涉及协程、调度亲和性、buffer 复用率、变量逃逸等各种不如标准库，所以性能跑不过标准库。Poller 框架的优势是海量连接数场景协程、变量、内存可控，不至于 OOM 和明显的 STW ，内存占用大幅降低（百万 websocket 1k payload echo test 可以控制在 1G 内存）。 所以对于很多普通连接数的用户，我都是鼓励使用标准库的。 gnet 起步早、积累了很多用户，希望能实事求是，避免误导。  | 1 lesismal OP 之前没细看、看错了，说归类为剥离的那个人不是官方的。 gnet 作者 close lock issue ，所以没法继续在他的 issue 里说这个问题了，把对他的回复放到这里仅供吃瓜娱乐： related: https://github.com/panjf2000/gnet/issues/733 之前没仔细看，不是官方的列为” Stripped/剥离“。但不影响这个事情的本质。 https://github.com/panjf2000/gnet/issues/733#issuecomment-3398069779 > 你这人到底是怎么回事？首先，README 上已经清楚明白地写了 techempower 测试榜单上的 gnet 的 HTTP 实现是非常不完整的，我都说明了 gnet 那个实现不是生产可用的，而是专门用于压测的；其次，gnet 以前的 issues 里就有好几个讨论过 techempower 榜单了，而且 techempower 仓库下面也有我曾经创建过的 issue 和 PR ，都对这个事情说明过好几次了，gnet 这方面的信息一直都是透明的，我一直以来的观点都是 techempower 是作为压测性能的一个榜单的参考，而且我印象里你都在这个仓库下面说过好几次这个问题了，我都回复那么多次了，你怎么还在胡搅蛮缠？ > 还有，之前有很多人在 gnet 的仓库下创建了 issue 提问题，然后你跑到那些 issue 下面拼命地宣传你自己的开源项目，我之前已经警告过你了，你现在还变本加厉了是吧？无缘无故翻出 techempower 这个我早就澄清过几百遍的事情，在这个 issue 里又夹带私货把你的自己的开源项目宣传一次，我真是忍无可忍了，你这人能不能把自己的时间花在有意义的事情上而不是天天跑来 gnet 的仓库蹭热度？开源社区最重要的是分享和讨论那些有创造性的代码和想法，而不是天天在社区里无端地去抹黑和攻击别人，希望你能好自为之！！！ 本来不想再给你提这些问题，但是隔三差五就有一些公众号作者，发文章吹 gnet 性能，而且是以 TechEmpower 的 HTTP 性能结果在吹 gnet 的 HTTP 性能，这已经是好些年的对社区造成了误导的实际情况了。 并且你没有在 README 或者任何明显的地方、包括你宣传的文章帖子，没有进行有效的澄清和说明，issue 里提到过的也都关闭了，通常用户不会去翻到 issue 才知道真相。 所以，这种误导一直在持续。 当然无法指责你是主观故意利用这种虚假宣传误导用户获得更多 star ，但实际的效果确实是这样的。 提到我自己仓库，只是想告诉你，gnet 功能性能都很一般，gnet benchmark 的代码里曾经有依赖过 nbio 、nbio 的 used by 里有过，但后来删掉了、应该是有人提交过后面被你删除了并且清理了 git ，至于原因我就不猜测了，大家心里清楚。 另外，我不需要蹭热度给自己涨 star ，因为我已经不做程序员了，而且 nbio 我也已经放弃。 放弃 nbio 的原因，如上个 issue 说的，多数用户的场景不涉及海量连接、用标准库性能更好，而涉及海量连接的场景的基础设施，c/cpp/rust 性能更强开销更低，新项目用 rust 更适合。 nbio 的一些改进的地方我早已知晓，例如改纯异步、支持 protocol stack 方式的解析，buffer 一对一分配释放，http body 不用等到读完就可以触发 http handler 、后续 OnBody 等等。但是如上所述，这些改进都不重要了，所以我没有继续改进了，而是放弃了。以后用业余时间再维护下给老用户或者交流就罢了。 你要是只敢快速 close lock issue 而不是正面去处理，始终用这种虚假的方式宣传、维护这份虚荣，那随便你，但这并不是好的方式。 如果真正开源精神献社区的态度，请你正面说明和澄清下 gnet 性能的误导性问题，而不是让虚假的东西继续。 当然，不澄清是你的自由，但是，别人隔三差五给你说这个事情的时候，你还能问心无愧的时候，那也请你不要嫌烦。 注意：正面说明，应该在明显的地方，而不是犄角旮旯、大部分人看不到的方式。 |
| 2 lesismal OP 除了 gnet ，作者的 ants 协程池的库，我们很多人测试也是没跑出他所谓的比别人强的指标来： https://github.com/panjf2000/ants 净搞这些没实际用处的然后一顿吹、骗小白 star 很多 star ，实话实说怎么这么难，什么世道。 |
Select Language