@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 的代码、暂时没有分析慢的原因