正常业务单个连接 1s 发 1000 个包早就被限流 close 了，-r 1000 比-r 500 更不合理+丧心病狂😆。。。

这种非正常压测导致 tcp 缓冲区堆积时，nbio 的异步解析器需要处理更多包边界、半包缓存，可以提高 nbio 的读缓冲区 size 来提高一点，但毕竟已经是不合理测试参数，具备这种高频的场景能想到的只有 rpc 服务，但是 rpc 服务不需要太高在线量，所以用同步方案更好、不需要基于 nbio😆

建议-r 10-50 。连接数 1000 太少了，nbio 欢迎连接数 10w 起步百万更好的压测来暴击😆

刚刷到下面这个新闻，仅供参考：

[男子生前的信用卡欠款 58000 元#银行向家属索赔被要求证明亲属关系#]
近日，浙江台州一男子去世后，银行要求其家属偿还男子生前的信用卡欠款 58000 元，但被家属要求证明亲属关系。随后银行将其家属起诉。经浙江省仙居县法院审理，驳回原告诉讼请求。据报道，由于双方发生争执，陈先生的女儿电话中要求“先让银行证明亲属关系，否则其他一切都免谈”，随即便挂断了电话。据仙居县法院民事判决书，因银行没有举证证明 58000 元用于夫妻共同生活，因此 58000 元不属于夫妻共同债务，其家人无需归还欠款。2 月 25 日，九派新闻记者从该案件被告的诉讼代理人吴峰燚律师处获悉，银行没有再上诉，“委托人对于案件的处理结果还是满意的”。 @九派新闻

@Nazz
我是真有点想搞 rust 了：
mp.weixin.qq.com/s/1dB4P54tVz-aM2iYIkE4fg

@zagfai
go rust 或者 c/cpp ，不是钻木取火。
如果这些是钻木取火，未来 AI 写代码成熟了，那时候的人同样也会说用 java php 这些是钻木取火、谁还自己写代码啊！？

过去这十几年，IT 这条线发展太快了，不知道 AI 迭代的速度会有多快，有生之年是否能见识到机器生命雏形甚至更高阶一点:joy:

@zagfai
你看 #19 我那句的完整顺序：
1. 先说的 “为了搬砖效率” —— 这个就是提高了部分生产力，因为提高的主要是开发效率 /速度、性能和软硬件消耗的成本是不划算的
2. 然后才说的“圈养了大批 CURDer”

科技线的演化规律通常是不同技术潮涨潮落逐步更迭到更好的，相比于 java ，go 的性能和消耗更友好，目前在一些其他语言舒适区使用者眼里，go 开发效率差很多，但毕竟出生的晚，随着逐步完善、开发效率越来越高，而且就我自己而言从来没觉得用 go 比用其他语言开发效率低。

但 go 性能不够强，只能做第二梯队、在开发效率与性能消耗之前均衡，在 CURD 与基础设施以及这两者的一些中间过渡领域会有很多作为。

往远一点看，rust 会大量占市场，目前阶段是 rust 已经进入，比如 linux 内核，比如 tidb 这种搞数据库的，比如 cloudflare 的一些基础设施：
https://mp.weixin.qq.com/s/1dB4P54tVz-aM2iYIkE4fg

再往远一点看，AI 的发展，未来大部分代码可能会是由 AI 直接生成更高性能的机器码，等到 NLP 、AI 编码更牛逼了，人类需求直接丢给 AI 了，配合上更丰富完善的测试验收体系。全盘丢给 AI 怕它作恶像终结者那样反噬人类，所以你看，OpenAI 的核心宗旨在于“实现安全的通用人工智能(AGI)”，使其有益于人类

性能是效率的永恒核心，是生产力的核心，现阶段你觉得够用了，并不代表其他人、next gen 也觉得性能够用。所以不要觉得 java 那些提高了生产力就没必要 go 和 rust 了，那只是 CURDer 这些不需要性能的人在坐井观天或者自欺欺人罢了

先走出自己的舒适区，然后不知不觉就破境了

@wuhaoecho
go 爹说的没毛病，我的这个 id (les is mal)也是 less is more 缩写拼接变换得到的
很多人嘲讽 go 大道至简，殊不知是他们习惯了搬砖的工作、而 go 不是只为了简单搬砖。。。

@MoYi123
> 不是 go 比 java 多了指针, 而是 java 比 go 少了指针.

这话说的妙极了

c 时代的 realloc 就是这样的，只是那些语言为了搬砖效率封装了一大堆、然后圈养了大批 CURDer

@Nazz c/cpp/rust 掌控力强，我就最喜欢 c void*，无拘无束，go 虽然写着省力写的快挺爽，但是找不到那种尽情优化做到极致控场的感觉，虽然爽但爽不到极致，只是均衡的感觉

@Nazz #32
我最早的时候是看到 evio ，国人又有人改进写了 gev 和 gnet ，想直接用他们的，但是功能太少了，只能用于 4 层，7 层自定义协议，tls/http/ws 这些统统没有，而且 gnet 性能略好于 gev ，但是没有实现 net.Conn ，想基于它封装也是非常麻烦，所以放弃了，自己撸着玩，慢慢就把功能加得越来越多了

@Nazz
好些个开源的 IM 项目用的都是基于标准库同步 io 的 conn ，真要是在线量大，他们那个服务器节点数量成本会很高，如果换 nbio ，估计能省掉至少三分之二硬件成本，集群内部通信用的 GRPC 如果换成 arpc 走 tcp 、性能又能提高不少。
nbio 最初的定位是解决 1m-connection ，几个月前还都不支持多 io 模式的，一般在线量的场景，纯 poller 的响应性能跟基于标准库的相比实在是没得比，现在平衡多了

其实如果放到量大的业务上做基础设施，都能省很多成本。但如果真的量巨大，公司有钱，还是 rust 或者 c/cpp 好些。前阵子 cloudflare 说他们内部的 rust proxy 性能相当好

go 版本的这些，跟 rust/c/cpp 的相比，实在是撵不上了，如果还年轻，我就去玩 rust 了，但是年纪不小，玩不动了

@Nazz
对，得多弄点不同变量参数对比，鸟窝老师 rpc 的测试里不同参数对比就相对全面一些

tls 直接标准库 copy 一份魔改的，难度倒是不大，主要是琐碎，debug 、覆盖比较烦躁

@Nazz #46
不同的参数下，跑出来的数据是不一样的。 -r 500 这种，在正常的服务里限流机制直接就把它 close 了的。
不同连接数、包体、 -r 取正常值范围的情况下，你可以试一下看看各个框架带宽和消耗能跑到多少，我环境下得到的数据并不是哪个固定第一，cpu 占用有差别，有的 cpu 高一些但是同样获得了更高的吞吐，有的 cpu 利用率上不去、跑多轮也还是低消耗低带宽比较奇怪。框架数量太多参数太多，跑几轮下来我眼睛都花了

不能只以一种参数来确定性能

@Nazz
我能想到的高频发包的场景，比如 RPC ，但是 RPC 通常内网，TCP 更具优势（所以我非常抵制 GRPC ），而且 RPC 服务承载的 client 连接数并不会特别大，所以基于标准库同步方案、同步解析就 ok 了，我的 arpc 也是这样。但是 arpc 也支持 web 前端 client 直接通过 http/websocket 交互，这时候虽然可能连接数量也很大，但是这种用户并不是服务之间的 RPC 调用、所以也不会有服务之间 RPC 那种单个连接高频发包的场景、真有攻击的话它自己这个连接慢了也活该。。。

我暂时没看懂 tcpkali 有没有办法进行类似 echo 测试这种，发-收-发-收，这样即使连接数不是特别大也可以把 server 性能跑满、更符合实际场景一些，而不是像上面那样通过-r 超过正常需求范围的情况下打满

> 用普罗米修斯监控确实影响了测试 RPS, 同样的命令, 去掉监控后跑到了 8000Mbps, 加上监控只有 4400Mbps.

@Nazz
对，额外的重量级工具本身带来的消耗影响大，而且他们的消耗也不是平均持续稳定的、没法保障对不同框架测试时段的环境公平性，所以大家做压测通常不使用这些

@Nazz #42
我刚跑了下 tcpkali ，按照你的参数确实 gws 更快，但是我本地得到的数据差异没那么大。
netstat 查了下，tcp 收发缓冲区待读写的 size 较大、远超过单个包 size ，加上 tcpkali 的-r 参数你设置的 500 （每秒向每个连接发送 500 个包），这说明 tcpkali 压测方式是不管对方是否回包，都会按照-r 这个频率往对方发包。

nbio 的解析器是异步流解析器，在-r 500 这种测试情况下，相比于 gws 的同步读同步解析，nbio 要处理更多的包边界、半包缓存之类的，所以会不划算。但实际场景中单个连接 client 向 server 每秒 500 个包是不太可能的、fps 类也远低于此。server 端推送也不会有这么高的频率。如果是有人来攻击 server 、这个连接响应慢了也不怕。

1000 连接这种，如果把-r 调整到正常交互频率，性能就都差不多了。

我又尝试把-r 20 、连接数提高到 2w ，nbio 的数据会更好些：
tcpkali -c 20000 --connect-rate 5000 -r 20 -T 30s -f ./1K.txt --ws 127.0.0.1:28001/ws
2w 连接 gws 遇到过一次不知道是不是触发了 bug ，2w 在线、协程数却达到了 3w+，tcpkali 30 秒竟然也没返回，不知道是不是 tcpkali 测试 bug 导致不断有新连接才导致 gws 协程 3w+，忘记了保存现场、后面多跑了几轮没再遇到，所以暂时没法分析这个了

更大连接数用 tcpkali 不太好测了，多个节点一是卡、二是建立连接的时段不一样，有的节点建立连接后就开始猛发数据把 server 打满了，新节点再进入就困难了。但一些海量连接的业务的话可能是连接数多但频率没这么高所以新连接进来速度也还好。
这也是为什么我之前没用第三方的工具进行百万链接的测试、而是自己写 client 来测试的原因：
https://github.com/lesismal/nbio-examples/blob/master/websocket_1m/client/client.go

tinyws 在-r 500 的情况下跟 nbio 差不多可能略慢，我没看 tinyws 的代码、暂时没有分析慢的原因

@Nazz 运维用这种监控集群健康挺好，做 benchmark ，尽量保持测试环境稳定、少部署额外软件好些

@Nazz go 做简单 curd 确实不难，但是这种遍地并发对绝大多数人来说都挺难的，chan 适合解耦、串行化，能避免并发不熟的人一不小心就死锁了，但是性能肯定差一些