PHP 部分改造为 go 与全部改造为 go 是否会提升性能？

swoole/swow 就是解决 io 阻塞问题的，swoole 不能缩短单个请求的响应时间，但是可以搞定并发。php-fpm 下 100 个请求就要 100 个进程，swoole 下单进程就可以

完全改造就不需要 PHP-fpm 了，参照 alist https://github.com/alist-org/alist

为什么这么多人认为 go 写业务难的，我从 php 转 go 感觉可顺畅了，php 能做的 go 能做，不好做的 go 也能做

不过重构容易踩坑 可以考虑下 webman

新项目无所谓，改造的话，业务包袱重，不建议。为了绩效，那就选自己不熟悉的吧

以我处理过的情况来看, 只要把 php 和 go 的 session 同步起来, 改造起来应该是比较顺畅的. 如果是前后端分离的架构就更好了, 通过 nginx 或 apache 代理来转发请求, 也可以做到无感切换. 处理效率上来说肯定是有提升的, 这个都不用怀疑. 也可以用 swoole 来做这个事, 看团队更熟悉哪个吧.

@rekulas
因为写业务有更好用的语言，那不当然显得 Go 麻烦嘛。

如果你的 php 代码都是请求第三方接口的，时间不会减少。go 能加速的只有中间件连接的时间跟微软的代码执行时间。像我司的业务很多都是请求内部大数据接口的业务，接口本身都 1-2s 的时间，go 能加速这个时间？

@Twnysta 都是内部接口的话，直接 rpcx 会不会是更好的选择

ssh 哥挺活跃

业务有需求吗？

没有需求这不就是面向简历编程吗。。。。不建议拿生产系统玩票。

没啥问题 我就是无缝切换 看公司给你不给你时间了

不如升高 php 版本

我们日均千万 PV 并没遇见 PHP 语言方面性能的瓶颈，OP 确定是语言的问题？

swoole 还不如用 golang 重写呢，工具链及相关生态极度不完善，用起来一堆坑

@nuk 题中所说 100 个 fpm 进程只是举个例子，当然还得看机器配置。。最主要的意思是如果本身 100fpm 出现了当前的问题，那么我再在当前机器上加入改写的 go 的应用，把一些依赖外部网络请求的部分放到 go 里，是否能降低 web 请求响应时间、是否能降低机器 cpu 消耗


@everyx 是的，大量的 tcp 连接建立和销毁以及 php 进程在网络 IO 阻塞导致的切换。。我现在是想对这方面进行优化


@Twnysta 你所说的“时间不会减少”要看是什么的时间吧。。。如 34 楼老兄所说，如果我有非串行依赖请求，那么我可以用 go/swoole 尝试进行并发请求。。另外把 php 没有连接池、频繁建立和销毁 tcp 连接、频繁网络 io 阻塞导致的进程切换时间都用 go/swoole 来尝试改造，这部分的时间还是能减少的吧。。我所指的能减少的时间是“我服务端对客户端的响应时间”

---

[另外最后再补充下啊] 当前公司给的目标是服务器等成本降本，当前服务器配置下日均 pv 也是千万，业务应用能正常承受，是没问题的。。。所以我的重点目标还是继续优化性能，看看能否再减少服务器。。所以目前找到的优化点是这个 php-fpm 下的网络请求 IO 阻塞问题。具体大家可以看下前面和大家的对话。。实际上 swoole 与 go 都可以，但再出于后期找工作的考虑，所以想选 go ，咱就不再在 go 还是 swoole 等上面纠结了。。咱们就讨论用异步 IO 、连接池、协程处理并发等方面看看能否将传统 php-fpm 模式下的这个问题进行优化？

典型的 PHP-FPM 进程模型的低效 IO 等待问题，你换任何一个异步非阻塞的语言/框架都可以解决。
引用我以前的回复 https://ex.noerr.eu.org/t/822487#reply65
“很多人说你的项目压根用不到语言的瓶颈，但他们往往说的是计算瓶颈，而不是 io 瓶颈。很多 php 用户没搞清楚“异步里面不能套同步”就上 swoole ，就和很多 python 用户在 tornado/fastapi/asyncio 里用内置 file 等 io 阻塞型函数，java 用户在 netty 里用 jdbc 那样”

识别出来之后，其实剩下的方案选择更多是“政治”问题，因为不同的公司文化在这种情况会出现不同的选择。很多技术选型其实是最上面的技术管理当时拍的脑袋决定的，就看现在这个脑袋由谁来拍了。


坚持用 PHP 方案解决的理由无非是团队里擅长这个，你贸然更换技术栈之后出了事故没人兜底，各种疑难杂症没人解决，看你决心而已。当然为了让其他人更好的支持你，你最好写完之后，把各种常见 PHP 代码片段的 Go 实现贴出来，搞点技术分享，帮大家快速入门，大家爽了之后就会更愿意支持你。

这里可以给一个说服你用 Go 的理由:现在百度旧项目要让用 go 重写，新项目不能用 PHP 。

另外，你的问题其实就是要做到“全链路异步 IO”，需要从最入口的位置开始做全链路异步的方案替换，这种问题都是越早改造收益越大，很多问题一开始选对方案就根本不会出现，加班都不需要。

反例就是各种 java 技术栈公司累死累活的改造，还有经常在站里吹的“动态线程池”方案，没有问题愣是给你创造问题:
https://my.oschina.net/u/4273516/blog/4543708
https://juejin.cn/post/7239895900296888376

没有性能瓶颈，没必要。。go 更容易出问题

肯定会提升性能，但是增加开发成本与维护成本。go 程序员与 php 程序员薪资考虑一下

@shuimugan 异步里面不能套同步？ swoole 下 io 阻塞都能 hook 掉，不存在阻塞啊