TechEmpower/FrameworkBenchmarks 把假 HTTP 框架归类为“Stripped/剥离”了

等了几个月终于有动静了：

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 起步早、积累了很多用户，希望能实事求是，避免误导。

lesismal

10 小时 43 分钟前

之前没细看、看错了，说归类为剥离的那个人不是官方的。

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 性能的误导性问题，而不是让虚假的东西继续。

当然，不澄清是你的自由，但是，别人隔三差五给你说这个事情的时候，你还能问心无愧的时候，那也请你不要嫌烦。
注意：正面说明，应该在明显的地方，而不是犄角旮旯、大部分人看不到的方式。