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

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

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

代码发我下我试试看。多种 io Upgrade 后就没什么大影响了

@Trim21
有这种可能，但也得是反代跟 ws 服务内网或者至少同区、网络稳定才行，否则跨了公网就可能更高概率卡一下。

另一方面，既然它的目标也是解决海量并发问题，而且 ws 的协议功能没那么琐碎，自家反代加的这层节点成本也不低，还不如直接云 CDN 直接回源 ws 服务划算。
还有就是，gobwas 只能做到低消耗，相比其他 ws 框架，它性能几乎是最差的，我估计他们的业务本身可能就比较低频，所以即使用了问题也不大。

但按照你说的 medium 的博文搜了下，看到这句：
"Mail polling involves about 50,000 HTTP queries per second, 60% of which return the 304 status, meaning there are no changes in the mailbox."
原来 http 轮询的方式是 5w/s ，改为 ws 主动推新，加上一点心跳，频率要低得多，如果只是这个数量级，其实总量没多大，即使不用 poller 方案、多部署几个节点也随便搞定了

实际情况如何就不清楚了，但通用框架依赖这些特定因素才能稳定总不是好事情，哪天整个环境某个链条改变一下，服务就不稳了

我之前并不知道 gobwas/ws 这个库，还是之前一个人来我 repo issue 推荐我看，去扫了几眼就觉得不对，代码验证一下就确认问题了：
https://github.com/lesismal/arpc/issues/2#issuecomment-746694287
https://github.com/lesismal/arpc/issues/2#issuecomment-747258191
后来 nbio 里搞了更多，百万连接也没 gobwas/ws 这问题，终于可以省心了

@Nazz 我之前的简单压测是几个字节的 payload ，刚才又试了下 1k 字节 payload ，我环境得到的数据：
1k-1w 范围连接数时，tinyws 和 gws qps 差不多，nbio 略快，内存占用 gws > tinyws > nbio ，但内存差距不算特别大
10w 连接时，nbio 快更多一些，内存占用 gws 约 4.17G ，tinyws 约 3.73G, nbio 约 1.2G ，内存占用差距比较明显，而且 gws 和 tinyws 的 qps 不稳定、qps 摆动幅度较大，应该是连接数太多 gc 时 stw 更明显导致，nbio 的 qps 比较稳定
相同连接数压测的 cpu 消耗差不多，nbio 好像略低

@Nazz #27
这有点杀鸡用牛刀了，而且还是要统计 qps/tps 结合进程自己的消耗，压测里自带这些工具就可以的，比如字节这种：
github.com/cloudwego/kitex-benchmark

但是字节这个 perf 不跨平台，我自己用 gopsutil 简单封装了些：github.com/lesismal/perf

@guonaihong 我是超级不喜欢 grpc ，哈哈哈，用我自己的 arpc 一把梭才是爽。。。

@Nazz 是啊，多个框架跑一轮还得统计很麻烦，而且可以测试得内容太多了，tls non-tls http ws rpc 各种，所以一些项我也只跑了简单测试

@guonaihong 好像很久没出现了，是在忙着搬砖嘛 :joy:

nbio 的 websocket 解析器，是支持异步流数据解析的、同步 io 的数据丢进去也一样解析，所以本身是有点吃亏的、逻辑比同步解析复杂得多，而且涉及半包 cache 之类的，否则只是同步解析，还能实现得更快。同步和异步 io 都能处理，所以结合自身的 IOModMixed ，能把性能和硬件消耗做到最佳，不同在线量全 cover ，其他框架高在线量太吃硬件资源了

@Nazz #9 gws 不是一骑绝尘的。。。你看我 #19 ，你把 tinyws 和 nbio 的 IOModBlocking 和 IOModMixed 也跑来对比下试试。。

@dw2693734d
哈哈哈，没参与日常维护，就之前偶尔读了下 melody 源码，发现那有个并发的问题会低概率导致 panic ，肉眼看出来，写测试一模拟果然就复现了，然后 pr 了下，那时候正好是疫情严重时期，作者消失很久了，我都担心他会不会感染了严重了之类的，还好后来他又出现了，并且 merge 了我的 pr

一些知名库的作者对并发这块的实现其实也不够好，一是被 go 官方和很多人鼓吹要用 chan 、少用锁，二是 go 这种多并发流确实复杂、肉眼难看出问题、测试压测也很难测出问题、甚至没办法模拟复现只能靠肉眼和想象力。。。

最近一个比较火的 conc 库也扫了几眼，接口设计非常优雅美丽，但是代码的实现也是受到太多尽量用 chan 少用锁这种观点的影响，所以它的实现是性能差一些的，不过这点性能损失对通常的项目也没什么影响、也还好

@Nazz
我这简单测了多个，tinyws ，nbio ，gws ，都高于 gorilla 的，三者数据差不多，连接数不是特别大的时候，我环境下 tinyws 略快一点点，nbio 、gws 差不多，nbio 的内存占用最少，连接数越大，nbio 会越均衡。没有做大量测试，比如不同 body size ，综合情况没做统计：
https://github.com/lesismal/nbio-examples/tree/master/websocket_1m

@Trim21
不知道他有没有把 gobwas/ws 用于他们大业务量的项目。
但 gobwas/ws 的实际问题是存在的，所以跟它用到哪里了不是直接关系，有问题就是有问题，只是可能问题影响范围他们可以接受，但并不代表别人的业务也能接受，尤其是被别人盯上随便来攻击一下的时候，影响要更大得多。
而且你看他的 issue 列表里也确实是别人提出了生产环境遇到了问题，我在那里讨论，他都是想着 timeout 之类的方式去解决，但那并不能解决问题。所以我才说它需要“三靠”才能稳定。。。但总不能大家项目都“三靠”保平安吧。。。

@0o0O0o0O0o
哈哈哈，感谢关注支持！
刚看到 melody 里有人提到因为 gorilla 不维护了、要不要切换到基于 nbio 或者其他基于框架，我也去凑热闹回复了下
https://github.com/olahol/melody/issues/73

nbio websocket 直接基于标准库 http 的例子以及多种 io 模式的说明：
https://github.com/lesismal/nbio/releases/tag/v1.3.5

旧帖发了那么久，一条回复都没有：
https://www.v2ex.com/t/892703

1. gorilla 虽然不维护了，但是生产被用了那么多，已经足够稳定，可以继续使用，从另一个角度讲，人家足够稳定没有必要继续维护了，凭什么就不能用了
2. 基于 gorilla 的 melody 接口设计比较不错，推荐
3. gorilla 虽然不错，但性能一般，而且需要类似 melody 那种做些额外的封装，比如广播场景需要单独的写协程、否则遇到单个 conn 阻塞可能导致其他 conn 被卡
4. fasthttp/websocket 在 gorilla 基础上改造，性能也一般


推荐下我自己的吧：
https://github.com/lesismal/nbio

1. 可以直接基于标准库 http 的框架之上使用、性能好于 gorilla ；
2. 可以使用 nbio 自带的 poller 作为网络异步 io ，能够支持海量并发比如百万连接，而其他基于标准库阻塞 io 接口的框架连接数太多时协程数量太大，内存容易 oom ，gc 容易卡顿；
3. 支持多种 io 模式，IOModMixed 模式下能够同步阻塞 io 与异步非阻塞 io 共用，新连接到来时根据当前在线量是否在设置的阈值以内，低于阈值使用标准库的同步阻塞 io 接口获得更高性能，高于阈值使用 nbio 的异步非阻塞 io 、协程数量最高占用配置的数量、动态退出，协程数量、内存各项占用均衡稳定
4. 不需要额外封装读写协程，只需要设置好 OnOpen/OnClose/OnMessage/KeepaliveTime 等用户需要的参数，用户专心处理业务逻辑

@0o0O0o0O0o @learningman 欢迎也来瞧瞧。gws 比较新、我也有提 issue 可以看下

企业招新人给的新人价格，老员工带一下都不会，可能是需要反思一下自己的管理能力了。

如果现在的“领导”带团队不行，那公司可能要考虑高价招经验丰富的人进来了
如果用高价招到靠谱的人进来，那不一定谁带团队了

三分天注定，七分靠打拼。
我觉得:
1. 认知应该属于打拼的部分
2. 七分天注定