@shaoyie #97

> 减少 syscall 次数，而且有了这个前提 大部分情况 ET 模式反而会浪费一次 syscall

这个可能不太准确：Edo while 条件+ONESHOT 需要重新添加事件，这种才会需要更多 syscall ，如果都是单次读完当前数据的话，ET 和 LT 是一样的。

> 而在水平模式下，读出来的数量小于你的 buf 长度 就可以了，不需要再尝试一次

除非你的读 buf 长度大于 socket 设置的读缓冲区 size ，否则不管 ET 还是 LT ，读本身是没法保障单次读出来的数量小于 buf 长度的，因为有可能 socket 读缓冲区数据量大于读 buf 长度

这里的 do while 条件也不是尽量读完，例如 socket 读缓冲区有 33k 数据，buf 是 32k ，本次读到 32k ，则不满足你的 (ret == -1 && errno == EINTR) 条件。
但这也不能算 bug ，因为你默认用的是 LT ，即使本次没读完、下一轮 event loop 也会继续触发读，只是相比于单次读完，这样需要内核在下一轮 event loop 继续派发可读事件、这样未必最优。

> 庆幸，昨晚程序能跑起来后我就第一时间做了对比测试，数据很惊讶

niubix 实现的功能本身就不是完整 http 相关功能、比 nginx 、haproxy 的逻辑少很多，所以比它们快也应该是意料之中，OP 为此惊讶这件事让我感到狠惊讶！

@shaoyie #85

1/3/4： 既然是这样，就不要用 qps x3 nginx 、haproxy 这种标题了，完全没有可比性，至少标题指明用于特定场景优化会好些。
nginx 的行业地位比自定制的玩具 demo 稳多了，这样标题、大家看了第一感觉就是你在碰瓷 nginx 、吹牛+踩 nginx 弱鸡，就像突然蹦出个民科一顿言论吊打数学家科学家一样。
goev 的帖子也是如此。

> 2. splice 是限于 pipe 。ZEROCOPY 是异步的增加复杂度了，buf 机制也要改，整体提升非常有限

按现在的功能，如果只是转发 backend 给 client ，应该不需要改太多

简单扫了几眼代码，没全看，大概明白为啥 niubix 性能这么高了，只扫了几分钟、不保证我说的是准确的，如果有误，OP 和各位多多指正。

1. 对 client 端请求的处理
https://github.com/shaovie/niubix/blob/main/src/http_conn.cpp#L168
这里的 http request 处理，目测似乎并没有做完整的 http 协议解析所以也没有请求合法性校验之类的，也没有 nginx 那些完善的对请求进行中间处理的功能，主要是添加 realip/x-forward-for

2. 对 backend 端的处理
https://github.com/shaovie/niubix/blob/main/src/backend_conn.cpp#L74
看这里是对 backend 读取到的数据直接转发给 client 、没有进行 http 协议的中间处理。但 nginx 是有处理功能的、比如开了 gzip ，backend 没开 gzip ，nginx 是会自己加上 gzip 逻辑的，也包括其他通用功能的处理。
另外啊，如果只是需要盲转发数据，其实用 splice 这种 zero copy 的 syscall 性能更好。

所以综合下来看，相比于 nginx 完善的功能，niubix 目前版本对 client 、backend 的处理都是功能不完善的、还属于 demo 级代码，或许适用于自家特定业务的优化，不适合作为通用功能的反代。

这种 demo 级的测试，跟商业级稳定大项目来对比性能本身就是不合理的，就像我之前给 OP 说的那样：拿不完整功能的 http server 去参加 TechEmpower Plaintext 没意义。

@mengdodo #14 网页回复随便打打字，见笑了，我下次注意！😋😋

@assiadamo #12

游戏的单服务在线量不会太大，举几个例子：
1. MMORPG 同屏/同地图 CPU 计算量大、通常要分区限制单个区人数，所以单个游戏服在线也不会很大
2. MOBA/FPS 类也是 CPU 计算量大但没有大地图的广播消耗，单局游戏/单个房间也是玩家数量不大、最多也就 10 个、几十个，所以战斗服务器横向扩展堆机器就够用了
3. 反倒是那些轻量游戏，比如休闲类的、弱单机轻状态的游戏，玩家之间的互动性较少，也是可以横向扩容堆机器，但是这种对 CPU 消耗不高，所以如果用 Poller 来节省协程数量的话，单个服务能承载很多玩家在线、节省服务器软硬件资源


所以除非是做上面的 3 中这一类，否则单个游服没多大在线量。普通在线量的场景，自己搞 epoll 这些框架的响应性能并不如标准库方案，因为通常需要 IO 与逻辑协程分离，跨协程的变量逃逸、变量生命周期不容易 pool 复用优化，还有其他一些细节，各种因素加起来，响应性能不如标准库方案。
所以如果只是为了游戏服务性能、并且不是上面的 3 ，建议 OP 不用研究这个问题了，自己感兴趣倒是可以继续深入

建议前半年报健身班+考证，后半年直接入职健身教练，健身、工作两不误，一年后如果收入不行再考虑换工作

绝大多数人处理的连接数都不算大、用标准库足够了。

@coderxy #3
@voidmnwzp #7
少量人需要处理海量连接、节约硬件、提高服务稳定性，nbio 简单压测 4c2g 跑 10w qps
https://www.v2ex.com/t/945827
标准库方案，差不多得 10g 左右内存了，cpu 核心数也得多些否则 gc 压力大、stw 不友好、稳定性低

另外 nbio 本身支持 http 、websocket 的连接采用标准库 Conn 、阻塞模式，只是用 nbio 的解析器，性能好、占用平衡

@securityCoding #4 gnet 自己支持的东西太少了，扩展起来也比较难，欢迎 pk （性能、功能、易用性都可以 pk ）

如果是亲爹，不至于对孩子这么狠！
如果不是亲爹，不至于这么卖力培养孩子！

所以我迷惑，到底是不是亲爹行为？

看到 cloudwego ，我来凑个热闹，我这也有 rpc 和 poller 框架：
https://github.com/lesismal/arpc
https://github.com/lesismal/nbio

related:
https://colobu.com/2022/07/31/2022-rpc-frameworks-benchmarks
https://www.v2ex.com/t/945827

@Grayan 欢迎来试试我的库啊 :joy:

@murmur 有道理！不过现在这经济状况，估计国内低代码平台离 aws 也不会太远了

不推荐这玩意，可参考 “一个潮流的终结？推出仅 3 年后，亚马逊宣布终止低代码 Honeycode 服务，前员工爆料：长期没有顾客！”：
https://www.infoq.cn/article/IddZNuobV3BLkWyAM3tZ

@voidmnwzp 是的。go 和 c 的编译器还不是特别智能，如果是 cpp 编译器、很多不这么明显的逻辑也会优化得更屌

表达式里含有子表达式这种，通常是要先计算子表达式吧，如果多个子表达式、c 里好像是不规定多个子表达式的先后顺序而是依赖编译器厂商实现。
go 的表达式规则我没细看，但是 OP 这段代码如果按照先计算子表达式，并且编译器推断那就是对比 a==a ，所以编译器直接可以优化了，看下反汇编的代码就优化掉了的：
https://gist.github.com/lesismal/71a96904de3a878c6ff27dd36e8fd4af

明明是 golang 的 if err 更适合错误处理、鲁棒性，一帮习惯了 java 的人喷 golang if err 。

也可以转 go ，游戏行业也有不少团队用 go ，关键是 go 转 web 开发、cloud 、devops 各种都比较方便。

继续深挖 cpp 也可以，看运气了

@zerone0086 我猜 1 楼是知道你说的措辞技巧的，因为他已经用 “有个朋友” 开局了 😄

他 git 提交的 username 是 zhaoxiaojiebj01
他 github 用户名是 zhaoxiaojie0415

Contributors 是按照 git 提交的 username 统计，两个不一样、而且 github 上没有 zhaoxiaojiebj01 ，所以不行

linus 喷 github 这个好像不只一次了。随便伪造个 xx 的提交

R.I.P

之前 op 反馈就回踩 star 了
8 年不容易，赞！