@xbchaonba #33 好嘞！欢迎使用，如果有疑问、bug ，也欢迎来 issue 、PR

@xbchaonba #30

> conn.SetReadDeadline(time.Now().Add(time.Second / 120)) 是要用这个方法更新吧

是用这个方法。
但你这个是 120 分之一秒，设置完后很快就过期了，如果没有立刻收到新消息，就 close 了

> 昨天试了好多次 u.KeepaliveTime = time.Second / 120 直接这样重新赋值没有用

同样的问题，估计也是因为 120 分之一秒太快了

@shermie #75

还有一个问题，你说的这个 PHP 协程，不管需不需要 yield ，会不会在使用系统调用、其他慢 IO 时阻塞了，因为已有的很多系统调用、慢 IO ，比如网络 IO 、操作数据库，如果这些底层接口并没有自动出让线程，那跟我前面提到的 Java 虚拟线程可能会是类似的问题。当你处理这些的时候如果阻塞了、线程就在那等待了，不能充分利用 CPU 、不是协程那种真的并发。我只是猜测、我并不了解你说的这个 PHP 协程哈

@xbchaonba #27

dev 修改了下，默认会开启读超时的更新，可以试下：
go get -u github.com/lesismal/nbio@a81e8e2

过阵子再发到新版

@GCP #26

椅子这种还是得试坐，而且最好不只是简单试坐一会，至少模拟办公之类的坐上个把小时才好体验出来。否则八成都是人体不工学。
而且再怎么舒服、它也是久坐，解决不了根本问题，频繁起来走动、运动比任何椅子都强，而且可以治疗、康复颈肩腰痛。

@xbchaonba #27

为了避免僵尸连接耗尽 server 资源，尤其是进电梯导致信号终断、移动信号切换信号塔、设备掉电等情况时，收不到 TCP 协议的 FIN ，连接一直无法退出。TCP 设置 keepalive 是检测四层链路健康，可以避免这种情况，但它并不能解决七层僵尸连接、慢连接的问题，因为四层链路可能一直是健康的，但这个连接什么数据都不发或者只发很少数据、仍然会耗尽 server 资源，所以七层的 keepalive 是需要的，有了七层、再做四层的 TCP 设置 keepalive 就画蛇添足了、没必要。既然应该做七层，所以就应该都设置读超时比较好，所以与其他很多框架默认不设置读超时不太一样，nbio 默认设置。

一直有发数据仍然断开是因为 Upgrade 过程中默认设置了 120s 读超时，但后续收到消息时没有自动更新读超时。
当前版本，server 端设置 upgrader.KeepaliveTime = YourKeepaliveDuration 即可自动更新读超时，设置 upgrader.KeepaliveTime = YourKeepaliveDuration 后，不只是 PING 、其他类型的 message 也都可以，因为是读到消息就更新超时。僵尸连接检测也不是必须要 PING 协议才行、有效的协议即可。
我考虑下，要不要把这个心跳间隔也做成默认配置、自动更新读超时。

如果不想设置读超时，可以在 Upgrade 后 SetReadDeadline(time.Time{}) 清空超时关闭。

燃风宁芝解君忧

网易严选名字起得挺好，但产品真没见过几个好的

要么买米勒，要么必须现场多试几次并且最好坐多一会再确定。否则，95 成的人体工学椅，其实都是人体不工学

@shermie #47

我搜了下，PHP 也有协程，所以我猜你是指 PHP 协程？
如果是这样，那我补充一点，除了 erlang 、golang ，多年前 lua 或者 c/cpp 也早就有协程或者库，但都是手动挡，比如 lua 的 yield resume ，我刚才搜的帖子里 PHP 的方式也是需要手动 yield 。
近几年 js py 之类的也搞了 async await 这些。确实，整体看上去是同步代码、顺序可读了。但是，这种手动挡理解起来并不直观，对于步骤层次不多的，个人觉得手动挡协程甚至不如 callback 。
nodejs 还有 Promise 这种，看上去是那个顺序，但并发的时序可能不是那个顺序，很多人因为这个写 bug 、或者理解吃力、或者要自己控制时序时非常麻烦。

很多人可能没有深度使用 erlang 、golang 协程，或者已经习惯了那些手动挡的蹩脚协程，所以 get 不到 erlang 、golang 这种像线程一样的并发有多爽。

Java 的虚拟线程还是啥也是类似协程，但似乎只是解决了语言指令级的调度，系统调用等行为并不会主动出让并可能因为阻塞占用了线程，我没有深入研究、不知道是否理解有误，但好像 Java 至少仍然需要解决大量的底层接口与虚拟线程调度结合的问题，这仍然需要很大的改造。

再补充一些，现实业务不只是 CURD ，PHP 的编程姿势主要是为 Web 服务，一旦有复杂的需求，用 PHP 实现起来会很蹩脚、或者浪费资源，比如游戏

#2 > php 很多业务场景 go 开发起来是无法胜任的

所以我觉得，你这个可能把现象搞错了。现象是 PHP 有众多轮子，并且未必需要高性能或者什么，用 go 去重新做成本收益不划算。就像好些人说企业级只能 Java 一样，其实不是 golang 或者其他不能搞，而是因为 Java 已经形成了成熟的产业链和社区，并且企业级的业务 Java 性能各方面也足够胜任。用 golang 或者其他语言去重造需要很长时间，而现实商业场景，没哪家资本愿意去推动这个。但如果是新团队重新造这些，是可以用 golang 的。字节系大量业务用 golang ，飞书应该也用得挺多的，人家有钱有资源有人才，就是可以搞。
除了极度性能场景是 c/cpp/rust 的天下，或者特殊专用领域，绝大部分的通用领域、绝大部分高并发高性能场景，golang 能搞、PHP 却未必能胜任。

@lifei6671 #25

你们的运维兄弟是懂怎么挣钱的。。。

最近好几次看到有人说脚本语言 ORM 牛逼，强类型语言 ORM 垃圾。

保持清醒一点好吗？弱类型 ORM 当然轻松了，但是你失去的是编译期检查，失去的是强类型系统规范安全保障等一系列优势。
ORM 只是让你获得了舒适区，就像刷抖音，很舒服，你获得了一些东西：比如你不太需要去思考 sql 语句如何写出来。但是你同时也大大减少了对不同数据集合处理的思考。如果是大表大数据集合，往往都是性能相关、对业务性命攸关的。当你习惯了只要 ORM 能实现业务逻辑的时候，扪心自问、有能力配得上去做海量业务海量数据的业务吗？随便一个 API 里的 ORM 生成的 sql 就可能把数据库卡住导致大量业务请求失败！
按照金字塔模型，这种层次的 CURDer 是开发者的主力群体，任何一个人保持在这个水平层次上都没问题，因为并不是每个人都需要去对高并发高性能这件事情负责，多数商业场景，随便写写都可以搞定。但是，如果是自己安于停留在这个层次，就不要出来拿性能说事、标榜我 PHP 或者我 Java 或者我什么语言很强了。或者如果自己想提升自己的技术境界技术能力，就不要把着眼前这点脚本语言的简单性能测试或者什么来对比了，参考我上一条回复，咱也不吹谷歌 golang 团队那两外老爷子和其他年轻一代的众神、因为其他语言的作者团队们也都是众神，但各个大厂的技术管理层跟进什么放弃什么是很有参考价值的、因为他们直面的就是工程领域商业战场，他们可不是傻子。

PS：我自己写 golang ，我也仍然经常说 golang 性能怎么也无法赶上 c/cpp/rust ，因为我也写 c/cpp ，我淘空了心思优化 golang 也仍然赶不上 c/cpp

建议 OP 多想想吧，那么多大厂跟进 golang ，人家的 CTO 、技术管理层，哪个不是背景闪耀、身经百战，哪个不是血雨腥风海量业务里杀出来的？你以为这些技术领头羊们都是弱智都是吃素的嘛。。。

另一个侧面，阿里当年从 LAMP 转型，放弃 PHP 到 Java 的时候跟 golang 也没关系，如果 PHP 给力还需要还 Java 吗？

别说什么 PHP 现在性能也提升了，语言指令性能的提升并不是性能的全部，只是一部分，甚至只是一小部分。
能写同步代码的编程语言，HTTP 服务的性能瓶颈多数时候都是慢 IO 占用系统线程。
能写异步代码的编程语言，又要面对 callback hell ，比如传统的 c/c++，脚本里 nodejs 。
简单 CURD 你不需要 RPC 、不需要各种基础设施的慢 IO 操作、你的 API 通常也不是海量并发，这时候一切看上去都还很美好，因为你搞定了业务、性能指标也并不比其他语言差，开发效率贼高，心里贼爽。
但是，如果接口里需要这些同步代码进行慢 IO 操作、并且会导致直接阻塞了线程，又遇到海量业务场景高并发的时候，系统线程数量瓶颈、并发度有限、会导致几何级的响应性能降级、请求积压，这时候如果跟那些异步非阻塞语言相比（ golang 这种同步代码但底层 runtime 实际上是异步非阻塞、不需要因为系统线程数量为 N 就只能并发处理 N 个请求，本质上也是异步非阻塞，但让用户可以写同步代码），差距就下来了。
所以别被那些语言指令性能的 benchmark 灌醉。

语言慢 IO 占用系统线程不只是 PHP ，Java 非 Netty ，或者 Java Netty+同步方式操作慢 IO 基础设施之类的，或者其他语言类似的方式，也同样有这些瓶颈。

@lifei6671 #4

> 是 Go 开发，QPS 几千，后端只部署了 4C+8G 的容器 70 台。😂

我怎么感觉你这是在黑 go 。。。QPS 才几千就 70 台 4C+8G 。。。
这么多 4C+8G ，如果瓶颈，猜测是你们数据库、缓存等基础设施瓶颈，日志量大 io 慢，或者其他这些语言无关的架构、系统瓶颈。否则我怀疑应该是你们 golang 代码写得太渣了。。。

对比下 golang 本身的能力：
https://www.v2ex.com/t/945827

嘲笑 golang 的主要群体是 curd boy ，这部分人对性能没有太大需求。
而且这些人中绝大多数自己都不熟悉 golang 相关的轮子就嘲笑 golang 开发效率低，按这个道理如果他们没写过 php 、ruby 、nodejs 、python 、c#等语言、则同样可以嘲笑那些语言效率低。

随便嘲笑吧，其实我们这些务实的 gopher 也真的不喜欢这帮人来 go 捣乱，看见他们把简简单单逻辑写成某些其他语言风格冗长的设计模式屎山，我们也很烦的。

所以，对于这部分人，请你离开，千里之外，咱们各自安好，各自都有美好的未来。

vsc 喜提 java250w

写 c/c++ 最大的感受不是成就感，而是 [ faster and faster, most of the things under my control ]，性能像利刃、针尖一样锋利无比，加上控场的感觉，确实很爽
其他脚本、带 runtime 的语言都没这感觉，比如 go 、再怎么优化性能都做不到 c/c++ 那样锋利的快感