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

[dandankele]

由于 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 全部替代了？

[EmptyDX]

可以一步到位，不过 golang 写业务有点难受

[Nazz]

团队没人懂 golang 的话可以先试试 swoole

[flyqie]

go 写业务还是有点难受的。。

你确定要这么干？

[flyqie]

@flyqie #3

而且 php 是弱类型。。。

迁移起来。。可能不太容易。

[wangritian]

先确定是否真的需要走这一步，看看实际 QPS 是多少
如果你团队的技术栈都是 php ，换 swoole 比较好

[yekern]

部分业务并发高的地方, 可以用 go 写, 然后用 nginx 转发过去 这样 原来 100 个 fpm 就可以降低到 50 个以下了.

[INCerry]

并不只有 Go 才有协程，PHP/C#/TS/Java/C++都有协程，你这个场景可以直接上协程，swoole 搞起来 IO 问题就解决了

[Vegetable]

不靠谱
建议不要做这种重构, 而是先把高负载高占用的服务挑出来, 重新设计实现.

[yekern]

其实 不建议用 swoole 如果是个大团队 有人可以搞 swoole 源码和二开可以搞搞, 没有不建议弄 可以试试 workman 或者 webman

[dandankele]

@EmptyDX 主要 php 在组装数据方面写的比较爽。。所以我也不太想全部改掉

[dandankele]

@flyqie 那一般 go 用来干啥啊？不是说用 go 来提升 php 性能是比较好的选择吗？

[dandankele]

@yekern 好像有点道理，可以减少 fpm 的数量了，go 的 rt 时间相比原先 fpm 缩短了，如果并发量不变的话，少量的 fpm 是可以承住的

[flyqie]

@dandankele #11

话是这么说。。但是得看你实际情况啊。

老项目除非真的项目瓶颈，不然不建议大改。

改最好也是慢慢改，go 跟 php 比虽然会提升性能，但是 php 的很多东西在 go 写起来是有些麻烦的。

他俩走的路子区别还是挺大的。

[brader]

花精力研究这个，不如用 Go 重构。要么就别改

[coffeygao]

看你当下这个场景，我觉得 swoole 可能是成本最低的。

[dandankele]

@flyqie 是啊。。所以我来这问问没有经历过类似这样情况的的朋友。。换语言改造提升性能我也是想着只把性能瓶颈的地方换了。。但在考虑的时候想了主题中提到的问题，所以怀疑只把这部分瓶颈的地方换掉是不是不会有提升？所以才有了这主题帖

[japeth]

之前团队有个项目,单纯把 php 翻译起 go,没做任何优化,性能翻倍了

[leonshaw]

换 go 不是一样依赖外部服务？先找到瓶颈在哪

[dandankele]

@japeth 具体怎么说？性能翻倍表现在哪里？相同 qps 下 cpu 降了？还是相同配置下 qps 升了？还是啥的？

[flyqie]

@japeth #17

php 翻译到 go 。。

有点接近小重构了，这俩区别还是挺大的，你们原来 php 用的是 php-fpm 还是 workerman/swoole 这种？