@lesismal 刚测了一下 1000 连接, nbio IOModBlocking 跑了 2600Mbps, gws:dev 同步读异步写是 5800Mbps, nbio 兼容多种 IO 模式是有开销的吧

@lesismal ws 客户端我是用的 tcpkali, cpu 占用率超低

@lesismal 连接数太多 net/http 肯定干不过 gnet/nbio 这些实现的

@Nazz 就怕机器不够强大

@lesismal 用 Prometheus+Grafana 统计挺方便的，就

@lesismal 做测试很费时间，在测评里我只测了 1KiB ，

@Valid 大厂考虑得很多，字节的 sonic 优化得丧心病狂

@webcape233 差别在于性能，feature, 以及对 websocket 协议的支持程度.

@webcape233 golang.org/x 那个很挫

@0o0O0o0O0o nhooyr API 挺精简的，但 rps, latency, cpu 均不如 gorilla

@0o0O0o0O0o 可以看看我的 WebSocket Event ，借鉴自 JavaScript

@lesismal gorilla 比 nhooyr 和 gobwas 强多了，但性能和易用性不如 gws

自荐一下 gws, 性能在基于 net/http 的 websocket 实现里面可以说是一骑绝尘

### Features
- 无依赖
- 每个连接只会有一个常驻的协程
- 支持异步非阻塞 Write; 支持单连接内并发处理多个请求, 控制好了并发上限
- 默认模式下即可 100%通过 autobahn-testsuite websocket 协议测试

https://github.com/lxzan/gws
https://dev.to/lxzan/go-websocket-benchmark-31f4

@0o0O0o0O0o 谢谢老铁

就算是 Java, 11G 也太离谱了, 这是造了一个 redis 吗

转 go 吧

@lambdaq 一家公司内容易形成规范，同时存在 gRPC 和 gin 经常要写一些胶水代码

@lambdaq JSON 很容易做到这两点, 但是没看到流行的方案, 可能是因为 gRPC 太流行了.

@aper 字节的 sonic 可以了解下, 丧心病狂的优化.