@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 可以了解下, 丧心病狂的优化.

@lesismal gRPC 本身太重了吧, 不然不至于性能这么差.

@mikewang 不同之处在于我在输出观点: 大部分 gRPC 的使用场景可以被 JSON-RPC 平替.

@documentzhangx66 有很多高性能的 JSON 实现, 除浮点数外, 和 protobuf 差距不是特别大.

@guonaihong 我指的是对内对外统一使用 HTTP JSON-RPC.