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

由于 php-fpm 是以进程为单位提供服务的，大量 php-fpm 进程运行并接收客户端请求，当 php-fpm 极其依赖缓存、数据库等外部服务时，php-fpm 与外部服务之间的网络连接交互也会多，导致网络 IO 频繁，进而导致 php-fpm 进程间的频繁切换问题。这种情况经常在监控上显示为进程的墙钟时间比较大，cpu 消耗时间比较小。

所以在考虑如果用 go 改造的话，使用 go 去连接缓存、数据库等外部服务，php-fpm 充当纯前端 SSR 从 go 那里获取数据渲染页面。那么，在服务器资源配置不变的情况下，请求量与之前不变的情况下，应用性能是否会有所提高？这里主要指 RT 响应时间是否会缩短？

但是我觉得假设改造前是 100 个 fpm 进程，改造后还是 100 个 fpm 进程，并且还要增加一个 go 进程，100 个 fpm 依然要与 go 连接，依然会在 100 个 fpm 进程之间切换进程，所以在资源配置不变的情况下，RT 响应时间应该也不会变化太大吧？
难道需要 go 把 php-fpm 全部替代了？

NowTime

2023-06-30 21:13:27 +08:00

如果是 Laravel 的话，可以尝试下 https://github.com/hhxsv5/laravel-s 用 swoole 跑，代码改造不会太大，改造方法按照文档改即可
当然 Laravel 官方也出了个 octane ，也差不太多

---

我们一个 Larvel 5.8 的老项目，用 laravel-s 后 Response Time 变低了、所支持的 QPS 也更高了，改造成本低见效很快
现在我们这个项目新的迭代功能（ api ）准备用 Hyperf 搞了，用的携程还比较舒服

dandankele

2023-06-30 21:58:33 +08:00

@8355 差不多就是你说的意思，你举的例子是 php 在单个请求处理中，有着多个串行依赖请求外部接口，如果不是串行依赖的，来用 go/swoole 协程并发处理。我所想的是，把多个 php 请求处理（进程级别的，每个进程中处理着串行依赖外部请求）使用 go 协程并发来处理（协程级别的，并发处理多个请求，每个请求里还是处理串行依赖外部请求或者还可以再并发处理外部请求）。。

我目前还没打算重构，我还在评估我的问题用这种方式能否得以解决。。。除了你提到的这些，我这个主题帖的主要问题是在想这种部分重构的情况下，响应时间是否会有所提升。

目前 6 楼的朋友应该是 get 到了我当前的主要问题。。可以把这主题中的 go 换成 swoole 、java 等，但问题是原 100 个 fpm 进程还保留的情况下、机器配置不变的情况下，增加 go/swoole 是否会优化单个请求的响应时间

naixiaoxin

2023-06-30 21:59:53 +08:00

可能你的场景直接上 Swoole 会比重构 Go 更好吧？
首先是 Swoole 基于 PHP ，对于来说该有的都有
第二 Swoole 在 TP 、Laravel 等框架中都有官方、三方提供的 Swoole 集成方案。可以在较少的成本下完成 Swoole 的接入

dandankele

2023-06-30 22:08:54 +08:00

@everyx 我缓存也是走的网络 IO 。。。现在拿缓存数据也是慢。数据库也已经做过一轮优化了。我在 30 楼回复中留有了一些监控信息。。所以不知道是不是网络 IO 阻塞导致的频繁进程切换

happy321

2023-06-30 22:10:54 +08:00

https://www.workerman.net/doc/webman/
带数据库查询业务，webman 单机吞吐量达到 39 万 QPS ，比传统 php-fpm 架构的 laravel 框架高出近 80 倍。
带数据库查询业务，webman 比同类型 go 语言的 web 框架性能高一倍左右。
https://www.workerman.net/doc/assets/img/benchmarks-go.png

caola

2023-06-30 22:18:17 +08:00

@dandankele 我的项目已经慢慢的从 laravel 切换为 hyperf 了，
laravel 虽然有 octane , 但不支持协程之类 swoole 的特性，
而且 hyperf 很多是用 laravel 的东西，迁移框架的成本不是很大

akira

2023-06-30 22:54:59 +08:00

使用 go 去连接缓存、数据库等外部服务

并不会有明显改善。。。不但做不到肉眼可见的那种改善，有可能是整体对外都没有变化。。。

现代的服务器，语言导致的性能问题基本上属于可以忽略不计的，或者应该是做为最后阶段才需要去考虑的。

Actrace

2023-07-01 00:00:01 +08:00

php 本质上是 C 的超集，做了再封装而已。性能应该跟 Go 没什么区别。
问题是很多人喜欢给 PHP 添砖加瓦，整一些模块化，框架化之类的，做得好了方便业务，做得不好就会变成你所想的那样，不知道哪里的地方拖后腿。

因此很多人把业务从 php 迁移到 go 重做，就是把以前 php 时代胡来的坑都填了。
另外可能公司有钱了会请个架构师把业务梳理一遍，合理设计架构来避免短板。

那如果是这样，我觉得迁移到 go 也不是不好，只是苦了研发部的各位就是了。

nuk

2023-07-01 07:38:07 +08:00

100 个进程的切换还好吧，切换不会造成性能数量级的降低。这种由于外部请求造成的请求慢，换了 GO 也是一样的，没区别。
如果只是想让监控数据好看，可以这样，把事件等待和回调全部放在一个进程里做，其他进程只管预处理和分发请求。这样 wall time 就转移到单个进程，就会感觉几乎每个进程都在很努力的干活了。

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/953035

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.