@lesismal 以我多年 crud 的经验来看，似乎很少有人关心 write 是否返回了错误. 一般来说，在 write 之前业务逻辑都处理好了，或者开启了协程去处理错误，有错误关闭连接退出就好

@DefoliationM CloseCode 和错误处理比较恶心

@lesismal 使用 channel 异步写会增加一倍的常驻协程，我更倾向于广播的时候开启一小批临时协程

@lesismal 断开连接是自动的

@liuxu gws IO 错误最终会通过 OnError 返回给用户, 实际上 gorilla 的 IO 错误它内部也已经处理好了, Read/Write 返回的错误是用来退出循环的

@lesismal 正确的道路太艰难，纯异步地解析应用层协议😂

@lesismal 一开始和 nhooyr 测试的 gobwas ，rps 只有预期的一半😂
后面单独测试，rps 这块还是垫底的

@FightPig 是的

@Trim21 数据放出来了, gobwas/ws 的 higher-level example, rps, cpu 表现都是最差的

@Trim21 gobwas/ws 单独跑数据是正常的, 晚点放一下数据 😂

@Trim21 RPS 只有预期的一半

grafana 配置上传到 assets/config 下面了

10 代 u 系太容易发热降频了

@Nazz 小集群内做成无状态服务

@gemingsy 服务挂了让副本起来工作啊，每个编号的 Deployment 搞多个 Pod ，订阅同一个主题

@gemingsy im server 应该是有状态副本集, 把用户分配到固定的节点上.

做好容灾就行了

好丑, 怎么恢复原样啊

更新的时候只更新本节点颜色，记录下操作序列号(单调递增); 获取节点颜色需要递归到根节点，取最大序列号节点的颜色. 更新 O(1), 查找 O(logN)