说说现在是什么架构，是用 php-fpm 多进程模式， 如何处理 io 并发低的问题？还是 swoole 或者 CLI 模式来处理的

不一定全是 PHP ，高性能的任务可以交给 golang 或其它

swoole 凉了，可以用 workerman

现在主流的后端 php 方案还是 php-fpm 模式吗

并发要求有多高?不如直接抛弃 php. 用 Go 写算了.

高並發是多少

其实一直以来高并发都是个模糊的概念。其实吧 ，要是并发你的机器已经不能承受，应该是已经不缺钱了吧。

PHP 凉凉，Golang 永生

主流是 php-fpm 。可以先用 php 开发上线，后面看情况分接口转 go 。go 选个名声好的框架搞也不难的，phper 能玩通。

首先，cli 只适合异步处理队列任务，不适合处理 web 请求（同步）使用 swoole 的话，其实学习成本还是有点的， 除非你们是 Laravel 之类封装良好的框架，并且代码没问题。如果都要重新写的话，建议 Go 。以后换工作，简历也多个技能点，对个人没坏处。

其实还有更简单的办法：加机器

＃8 我目前就是你这个情况，之前用 php 搭建的轮子快速上线的，跑了 2 年多 发现业务多了， 发现经常有请求响应很慢，超过了 5s 。原本以为 swoole 之类的可以无缝切换，找了一圈没有啥资料。这么看来还是 nodejs 重新实现更快。

我用的 hyperf 没使用 fpm 了

＃10 多个机器 涉及到 sesion 同步吧

＃12 迁移成本如何，我是纯原生 php ，就封装了几个数据库的操作类，没有用任何框架。

无缝切换的是 webman(workerman)

webman + 1

必须 golang

如果用 laravel 可以看看(laravels)[ github.com/hhxsv5/laravel-s]的解决方案，如果是新项目就是用 hyerf 方案，如果不想学 swoole ，就用 webman 。这是 php 的全部 cli 模式的方案了

如果你之前用 laravel 的话迁移比较快 纯原生的话 估计比较麻烦

高并发对技术而言，是个架构问题，不仅仅是 QPS ，也有 TPS ，针对不同的场景，会有的不同的架构设计；每种语言都有她擅长的业点，因此不要总是想着用单一语言去解决所有问题。实际上大多数 PHP 的业务，传统的单体架构都能适用，一些要求性能的业务可以剥离出来做独立优化，实在不行再说语言层面的优化，譬如用 go 等语言处理(我不建议用 swoole ，本身并不是一个成熟的工业化产品，其维护团队并不稳定)，在业务需求前景不清晰的情况下，不要上来就按高并发的技术去设计，否则架子铺的太大，实际作用有限。

swoole 不是无缝迁移的, 你以为是把 php-fpm 换成 swoole 运行时? 实际上是要把 php 代码 换成 swoole 写法的代码

不是的亲，还可以自己开发新的方案。

不知道什么是高并发，我一个 PHP 的项目，4h8g 一天几万单，几千万请求，几百万用户，几亿记录。

后台业务，高并发有几十万人登陆后台吗？

推荐 Swoole

这不是啥问题，除非现在你是单实例部署，不然早该遇到这个问题了

我也在 workman 和 swoole 之间选择，似乎 workman 更成熟

我觉得你可以先说一下你的高并发是多高...我接触的所有项目在没 bug 的情况下出现高延迟都是数据库扛不住导致的 没有其他情况....

原生 PHP 框架单机跑 1000QPS 很难吗？你不要用它做基础服务就行，php 是用来做业务的。

推荐 webman ，基于 workerman 的框架 后台界面安装 webman-admin 即可。 选择用 swoole 的话就 hyperf 框架，可以使用 MineAdmin ，基于 hyperf+vue 的后台管理

上过 swoole 的车，不建议，什么库他都得劈个叉做个 swoole 定制版，这不是脑裂是什么？性能敏感还不如直接 golang ，懒得学你就用 webman ，舒服还得是 Laravel ，不折腾。

swoole 貌似生态不好，一直不温不火

2W QPS

roadrunner 加持，swoole 的代码修改成本太高， 需要自己的生态

我觉得大概率是你 sql 上的问题， 目前做项目到最后发现都是 压力全在 sql 查询上，把常用数据缓存到内存 就可解决大部分问题。如果确实是数据库这里有优化不够，那你用啥语言都区别不大。

swoole 走的 hook 所有 io 函数去切换 io .. 它的唯一优势就是可以直接用 fpm 的库 你应该没深度用过

高并发优化大多数情况下 是在缓存和 sql 优化或者在架构、流程设计以及代码优化上动手 和语言的关系 不能说没有 只能说没那么大吧。。。语言再快 写的一坨屎又有什么用 ！ 说到底还是看人！语言和语言（同样的代码）本身差的那几毫秒对于很多场景来说没那么大影响吧！ php 的话 开启 opcache 或者 swoole 、workerman

瓶颈大概出在数据库，先优化数据库看看

很多库都是单独进行过协程化的，不是直接拿过来就用的。

＃23 ＃29说的很有道理。php fpm 是访问拉起一个进程，如果同时 1k 用户请求一个数据查询服务器，意味着这 1k 的进程对数据库发起 1k 个 tcp 连接，即使是用 redis ，也是 1k 个客户端进行连接，实际中是这样用的吗？线程池、连接池类似的技术完全用不上。

是的 我现在阶段没有加 redis ， 一个登录扫描和支付扫码结果，直接去数据库查的，导致 tps 上不去

webman amphp

问题关键原因你确认是 php 的瓶颈，而不是 mysql 等瓶颈吗。我建议先把根本原因找到。

现在不是都直接用 GO 写了，谁还用这个。

先查查 sql 慢查询吧，频繁连接关闭数据库连接虽然耗性能，但不多，0.1 秒内基本能完成。

PHP 性能优化三板斧：1 ，php fpm 慢日志2 ，mysql 慢日志以及慢日志工具3, nginx access log 加执行时间和响应时间以及分析解析脚本大部分时候，你有 1 就可以了。性能优化，首先你得找到瓶颈在哪里。。。定位问题才能解决问题。。。离开瓶颈根源谈性能优化，就如现代医生放弃检查和望闻问切，能医好病人，那不是撞大运吗？

不如直接 go

我很想知道你们的高并发有多高？以前有个电商项目日活 300W ，php 5 都没问题

对的，生产大部分性能瓶颈都是数据库，实际面向用户的业务尽量抛弃数据库，数据交互用 redis+队列。我以前优化过一个项目，用 varnish 集群 + redis 集群 + php 集群，不用 swoole ，只用 nginx + php ，完全可以 hold 住 200W 日活的项目。

推荐直接 Go

那个是比较早期的情况，没有 hook 所有的 io 。我记得好像不知道 4.5 还是 4.6 ，开始支持 hook 原生 curl 函数开始，就只用 fpm 相同的库就行了。

目前使用自研的类似 roadrunner 方案，go+php. fpm 还是算了。swoole 我个人觉得生产用是埋坑

只是为了高并发，不想要 websocket 的话，直接 PHP-FPMj 就可以了，我测试过，带数据库操作的并发数比 node 多。

先确定性能瓶颈在哪吧，php 高版本 php-fpm 模式下常规的优化加上以后处理已经不是很慢了，大部分情况下都卡在慢 sql 上面

求求你，换个语言吧

你熟悉 node.js 的话，无疑直接用 reactphp 就行

『发现经常有请求响应很慢，超过了 5s 』？？？这种正常思路不应该是先做 profiling 看看为啥吗？上来就指望换个框架解决？？？

用的 easyswoole ，都支持高并发，实际上慢都是 MySQL 的问题。

为什么 5s,花在哪里了.感觉就 LZ 的描述.优化代码和架构就可以了.

另外, 建议 5s 都优化到 1s 以下

高并发用 redis + 队列，和用 swoole 有什么关系吗

绝大多数 互联网应用场景 并发能力 受限于数据源。 编程语言又能慢到哪里去呢。 如果谁家应用只输出 hello world 那当我没说

＃40php redis 连接数过多解决办法（ Yii,predis,phpredis 等） c4ys.com/archives/2421解决 nginx+php/java/go/python+mysql 下 time_wait 连接数过多问题 c4ys.com/archives/1609但是连接数的根源还是连接没有立即释放。先得解决根源的根源，前面很多人提到的瓶颈问题。定位瓶颈其实非常容易，根源一般是四大 IO （ CPU ，磁盘，内存，网络），如何快速有效地分析以及确定问题可能出现在哪一个上？确定后如何解决？这不就是架构师干的吗？所以，你缺少一个经验丰富的架构师。。。架构师很贵的。。。不过，本人提供性能优化服务，一次 2000 元，包定位，以及性能优化 1 倍以上，以及当次问题经验交流。

首先你得定义什么是高并发？然后你具体多少并发？然后你具体什么步骤是瓶颈？你就一个高并发，没有用意义

那不然还指望 fpm 那古老的并发模型吗

我现在都好奇你们 php 基于 fpm 那套东西是怎么做数据库连接池的

PHP 都是快男，用完就丢。。。。FPM 和 nginx 是会所，小姐姐在会所上班，快男每次去会所就能立马找到小姐姐，虽然不一定是上次那个。通俗易懂吧？

人生苦长，我用 golang

直接 roadrunner 没有负担

你请求慢确定是开发语言的问题？大部分请求慢都是数据库的问题，先排查数据库和静态资源吧。

webman-admin 及 mineadmin 两个都用过，说实话，两个都很多坑，尤其是前者，作为后端来说剩下前端开发的时间都在坑里还回去了

我们做阅读类和短剧类的应用 每天 CPA 广告稳定投放几十万今年过年的那一周 每天投放 200w+ 日 UV100W+ 日 PV 千万数据库用的阿里云 RDS Redis 也是用的阿里云 静态资源用的机房大带宽服务器托管自建 OSS 五台 8H32G ECS 做负载 MySQL 做业务数据分表用的 php8.0 + hyperf3.0 稳定运行说到高并发 如果没有复杂业务还行 fpm 无非是堆机器做负载但是除了开发语言 还有一个非常重要的点那就是跟你代码实现的关系也非常大至少在我们这种体量 你代码写的太随意 特别是涉及到数据库和其他 IO 方面会被无限放大 导致雪崩切换到 swoole 我觉得是平稳过渡的最佳方案你可以使用 Hyperf 重构业务 用最少的成本来过渡协程虽然非常好用 但是也不能滥用这要拥有了 Laravel 的开发效率又有了 Go 的性能

在 V 站 PHP 日常凉凉 不过写起 WEB 来是真好用

高性能的场景上 go 吧，一步到位

绝大多数性能问题都出现在 IO 上面能触碰到语言的寥寥无几。我遇见的最大流量也就是一天有差不多 400 万用户使用实际换算成 QPS 也没多少。4 台业务机配置也就 4 核心 8GB 内存，MySQL 8 核心 16GB 和 Redis 16GB 全是阿里云机器，后端用的 Nginx PHP FPM 程序框架还是 Laravel 和 Lumen 。仅在第一天流量突增时调整了 NGINX （子进程数）、FPM （进程数）、MySQL （最大连接数）复盘后发现我们仅用了简单查询，这在大流量下对 MySQL 较为友好。

先别急着换语言。当然如果换语言成本低，那无所谓，换。优化第一步，看现实的瓶颈在哪？代码能优化吗？数据库索引加了吗，缓存能上吗？以最小的代价来优化。再不行，可以有 roadrunner 等方式可以让 php 常驻内存，不过有内存泄露和污染的风险，取决于你的代码质量。最后，可以单独将 php 承受不了的模块用其他语言重构。其实我很怀疑到底是不是 php-fpm 的问题，真到了那种地步，规模相当可观了。

想说的上面的人都说了，应该先分析原因再考虑换框架。

你说 5s 的话 大概率不是 PHP 的问题你要是扣 200ms 提升到 50ms ，这种才考虑换语言

workerman ，挺好用

[如果同时 1k 用户请求一个数据查询服务器，意味着这 1k 的进程对数据库发起 1k 个 tcp 连接] 先不说 1000qps 是个啥概念，可以说大部分业务都没这么大及时这样也没啥，MySQL 还能被连挂了？实在不行加个 proxy ，顺带做了读写分离

慢到 5s 这个级别，一般都不是语言的原因。

慢到 5s ，与语言关系不大。1 、先看日志，看看响应时间。2 、mysql 慢日志，看看慢查询，优化一下 sql 、索引。3 、再不行，加上 redis 、mc 等缓存。4 、部分页面上静态化。

为啥吹 workerman 就非得踩一脚 swoole ？ 如果说 swoole 凉了，workerman 也好不到哪去

打算搞 swoole 直接上 hyperf ，现在 swoole 的 hook 非常强大，大多数 composer 包直接拿来用，楼上说什么生态的、兼容的都是不联网的家伙；不搞 swoole 也不打算脱离 php 就 webman 了，据说可以无缝迁移（个人更喜欢玩协程那套，对 webman 不了解）

webman + 1 ，ORM 也是可以直接拿来用，轮子在 composer 上面找就行了

顺便问下，广州深圳有没有内推高级 php 岗位？ hyperf 、webman 那一套都玩得转。擅长领域：ERP 、电商 MTM3MTMwMjUzOTc=

根据“这个世界都是草台班子”的理论，PHP 赛高，菜刀就是要挑最顺手的。

如果是已有系统，并发高的接口特殊处理一下，最小成本，等业务充分成熟模式走通重构一下也不是不可以

我这里也在做短剧，并发有时候能上到 13w / s , 在我来这里上班之前 swoole 常驻内存，数据库连接池，持久化也尝试过，现在还是 php-fpm 这一套求稳

github.com/reactphp/reactphp写起来最像 Node.js 的是这个。

上家公司应该是用 php 做业务当中请求量算比较大的了，千万级别的 dau 基本上都是靠本地起一个 java 连接池来代理本地的 php 对数据库这些请求 然后开 pm.max_requests 调到一个合适值，避免频繁销毁

我们最早的时候做公众号书城、现在做付费短剧，都是用应用海的方式付费推广，几百个应用一起上，几万个广告主、一百多万的计划定点上量，那时候是 fpm+workerman ，我接手后用 hyperf 重构的，前前后后什么问题基本都遇到过，主要是大量场景用到协程（比如定时 PUSH 推送，数据复盘统计），加上又能够大量缓解 QPS 压力（业务高峰时媒体端的监测链接和客户端的 QPS 极高），大部分组件自动协程切换，DB 和缓存的连接池调大一点，所以用的这一套方案，现在架构很稳，数据库也做了分表，逢年过节加负载就行了

找到瓶颈接口，然后用 golang 重写，如果是 mysql 瓶颈就用 redis 缓存，这样优化最快。 如果整体都瓶颈了就不好说了，可以尝试升级一下 php 的版本，毕竟最近几个版本都是性能优化。

推荐 hyperf+1 至于说 swoole 凉凉的人 怕是也没真正使用过 如果团队会 go 的多 那 go 也是不错的选择

好久没看到你在 learnKu 活跃了

好久没关注 Swoole 了，很多人对其印象确实是凉凉了，有大佬能分享下现在 Swoole 到底咋样了，我现在用 webman ，主打一个简单

首先分析 php 的瓶颈在哪里在不重构的前提下1. 如果只是代码慢，加机器其实可以解决2. 如果是连接 db 短链接耗时，那可以 sidecar 模式，用 golang 长链接 db 后，在本地生成一个 socket 文件，php 短链接本地 socket ，golang 中转（ Java 也行🐶，主要是可以避免重构）在重构的前提下，别用 php 了

可以把 php-fpm 本身当成一个池，由 nginx 接收请求，php-fpm 池处理请求，所以并不需要太多的 php-fpm 进程。如有太耗时的操作，应该考虑异步处理，比如 laravel 这类框架都有 cron 和 task 组件的。需要优化的是 php-fpm 处理每个请求的时间越短越好。假设一个进程处理一个请求 100ms ，那么只需要 100 个进程就可以实现 1000qps ，而产生的数据库连接不会超过 100 个

当年项目都是 php ，被折腾的不行，果断换 nodejs ，先用 thinkjs 过渡了一段时间。特别是物联网需求多的那会，php 相当麻烦，得单独启用 swool 。

PHP 的官方原生协程库叫 revolt.run ，基于这个的 web 框架有 amphp 大家可以用起来了