关于 PHP 高并发，请教各位

[minuo0day]

H5 页面的核酸系统，前后端分离，前端 VUE ，后端 PHP 自己搭的 larave 框架，数据库 mysql,Nginx ， 三台负载均衡的天翼云应用服务器，都是 32 核 64G ，一台数据库服务器 16 核 32G ； 基本业务逻辑： 用户端，进入页面绑定自己身份证号手机号乡镇信息等个人信息，前端凭借身份证号直接生成个人二维码，向医护人员出示二维码，1 个小时需要做 40 万人口的核酸； 医护端，手机号身份证号登录或者申请，登入先选采集点，扫开箱码，再扫试管码选择十合一或二十合一，再点击添加人员打开扫一扫扫居民个人码添加；

24 日早上 4 点 30 ，医护人员开始大量的开始进入程序扫箱码开箱，并在后台开始大量的添加临时采集点，于 4 点 58 分，CPU 使用率 100%，系统崩溃，日志显示，瞬间请求数 1 万 4 ，重启在进入还是崩；

24 日下午系统整体挪到阿里云服务器，也是三台负载均衡的服务器，三台 32 核 64G ，加了 OSS ，用了阿里云的云数据库 RDS 版，主实例 8 核 16G ，只读数据库服务器 8 核，压测 10 分钟 15 万人，和 4000 医护人员同时在线也崩了，数据库和应用服务器的 CPU 利用率都打到了 100%，为了保障第二天不出问题，临时调大了一台应用服务器调到了 52 核，并同时把读写的两台数据库服务器都调到了最大 104 核，第二天检测才扛过去。

问：我们虽然调大了服务器的配置，但调大以后压测 10 分钟 20 万人和 4000 医护在线，服务器承载 20%都上不去，但前端页面会变得非常慢，基本上 10 几秒才能打开，这种情况请大神指点

嚯，没想到引发了热议，对语言和框架就不评判了，目前确定 opcache 生效后，DEBUG 关闭后，5 分钟 30 万读和 4700 医护人员同时开管扫码加人速度提高了 10 倍不止，目前程序每个接口运行 1.7S ，速度很快，感谢各位大佬

“确定 opcache 生效和 DEBUG 关闭后”这个是一个确定语句，伙计们，勿喷
具体做了，直接取 redis 缓存，不用直接操作数据库，只有在用户更换采集点的时候去修改下缓存，以及而且大量操作的时候添加了一下锁；

已解决，数据库调整一下，不用分库分表，做索引，优化下缓存就解决问题了，大佬们不用讨论框架的问题了，FPM 是没有问题的

关于 QPS ，回答大家一下，崩的时候 QPS 才 7K 多，崩的原因是请求数过高，瞬时 1 万 5 ，导致 CPU 过载

[815979670]

话说你们当时已经预料到会有高并发场景了，为啥还要考虑用 Laravel 写，不说 Swoole 了 Tp 都比这个快。。。

[holystrike]

上 swoole

[justfindu]

是否尝试把医护录入和居民数据库分开. 码数据加密缓存输出.

[zhs227]

关键的部分使用更高性能的库重写，比如 swoole ，或者用 go 或者 java 。注意缓存和限流
larval 这种需要经过仔细调优才能达到很高的性能

[IDAEngine]

主要是要找到瓶颈在哪，服务器内核调度也要针对性优化的，按道理 Laravel 没这么差劲

[abigeater]

根据你说的，感觉后端好像也没瓶颈了... 前端的 js css 文件是从服务器获取？ 全部挪动到 cdn 上试试？

[isno]

收费分析系统，解决问题，你们接受不？ 接受联系我

[minuo0day]

@815979670
@zhs227
@holystrike
这个是历史遗留问题，一开始这个程序是单点预约检测的使用的业务逻辑，后来临时赶鸭子上架，改成了全民核酸的平台，没来得及

[v7788120]

php 不懂，java 还是有很多解决方案的

[leaf]

Laravel 就不适合高并发，我们之前一次活动也被他坑了，后面用 go 重写了核心。

[lp7631010]

不要告诉我 你们的前端资源是直接访问的服务器。。。

[gdt]

php 异步框架，swoole 或者 workerman 这些

[heyjei]

这种情况应该从应用层面去优化：
1. 数据库服务器和应用服务器的 CPU 100%，可以看到什么是进程占用大量的 CPU 嘛
2. 检查下 eloquent 是否有生成多余不用的 SQL 查询
3. 检查下是否有把数据从 MySQL 取出来放到 PHP 里面做各种循环、统计等数据计算处理
4. 检查下 MySQL 是否有查询没有走索引
5. PHP 有没有 opcache
6. Laravel Deployment Optimization 有没有做
7. Nginx 的静态文件压缩有没有做
8. Nginx 的静态文件缓存有没有做

[gy123]

nginx 是自己搭建的?一台?看看和 nginx 转发到其中一台后端服务时本地端口号用尽有没有关系?

[minuo0day]

@IDAEngine
@abigeater
瓶颈在接口请求，分析日志看到的是采集点调用的接口请求数量过高，递归把自己写死了，这个问题已经解决了，但压测的情况下，程序打开过于缓慢，这个问题不知道怎么解决

[minuo0day]

@lp7631010 不是

[gy123]

@minuo0day 打开慢,带宽打满了吗

[sheeta]

用 Laravel 就是个最大的错误，benchmark 排名垫底的玩意来做高并发咋这么想不开呢

[lp7631010]

前端资源放 oss ？搞了单独的域名配 cdn 访问前端资源吗

[leo108]

程序打开过于缓慢需要先确认瓶颈在哪，大概率是 API 响应慢，开启 PHP-FPM 慢日志，看看是在哪一步慢。

另外就是调高 FPM 进程数，改成静态进程数，因为 FPM 自身的动态进程配置很难应对短时间内爆发增长的请求。

[loca1h0st]

`前端页面会变得非常慢，基本上 10 几秒才能打开`
确认下前端资源是在 CDN 上还是在服务器上的，带宽是不是瓶颈

十合一或者二十合一可以不用一次性进数据库，先进缓存或者队列，慢慢进行消化，减少数据库的压力。

前端生成二维码的动作和医护扫描二维码的拆成两个站点，减轻压力

前端页面打开看看请求吧，有多少前端的多少后端的，哪些是可以降级或者不返回的

[minuo0day]

@gy123 带宽 100M 的流量计费模式，高压测的情况下，带宽 50%也用不了

[ersic]

参考一下，laravel 上线优化清单。https://learnku.com/laravel/t/24559
再查查数据库查询哪些地方能加缓存的，都加上。

[minuo0day]

@lp7631010 对，前端资源都放在了 OSS ，没有用 CDN

[minuo0day]

@heyjei 没有往 Nginx 想，感谢，这个值得排查一些

[lp7631010]

@minuo0day 这。。。cdn 用起来啊

[ersic]

实在不行，加上访问控制，慢点可以，别蹦了。

[lp7631010]

@minuo0day 而且要域名直接访问 oss 别经过服务器

[liuyibao]

最关键的一点，你的 opcache 开了没？ 之前有朋友一个服务器，是做微信小程序接口的，经常报警，负载能打到 90%，opcache 配好后，从来没超过 5% ， 另外楼上说的 调高 FPM 进程数，改成静态进程数，也是必要的，你这么高的服务器配置，开 300 个进程是没问题的。 @minuo0day

[lp7631010]

cdn 回源 oss

[dem0ns]

目测瓶颈在数据库字段索引上。建议前后端部署到不同的服务器上，前端高带宽，后端高性能。

[gy123]

@minuo0day 那感觉还是得确定看看哪里慢,比如对某个 api 埋点观察执行时间;sql 执行慢就优化相关 sql 或使用缓存队列等;接口返回慢,可能是大量请求过来线程被占用不能及时处理请求,看看是否加大线程以及是否开启了会话保活机制,关闭以应对大并发....个人浅见

[minuo0day]

@liuyibao 这些都有考虑到

[Ansen]

CPU 利用率在哪部分？ user sys 还是 io?

[minuo0day]

@leo108
@gy123
一会程序低频使用的时候，我们打开 PHP-FPM 慢日志低压测看一下

[minuo0day]

@Ansen user sys

[liuyibao]

@minuo0day 确定 opcache 生效了吧，那可能是慢 sql 导致每个请求过慢。 实在不行加个 swoole 扩展，laravel 现在官方支持 swoole 和 roadrunner ，配置进去可以试下。

可以写个 aliyun 的接口调用工具，高峰时动态扩容下机器。闲时再注销掉。

这个很久以前方便临时代理用的，可以简单参考下，现在的 SDK 可能变了。启动好后加 api 调用加到负载均衡里就可以了。

[liuyibao]

https://github.com/liuyibao/socks-proxy

[570956418]

你知道问题出在哪吗？是哪一步卡住了，那个页面有查询数据吗？现在是数据库高并发卡住了还是 PHP 处理数据卡住了？知道大概问题点更好分析一些，现在换框架可能来不及，不过有个 laravels 是 laravel + swoole 的框架，虽然不支持协程，但是性能应该比 laravel 好不少，关键切换过去，你代码几乎不用改。只是换了 PHP 的进程管理器。

[liuyibao]

https://laravel.com/docs/9.x/octane

实在不行是可以试下这个官方扩展

[des]

全是主观描述，多来点实际数据，不然不好给你看
参考具体 #32 说的指标

[liuxu]

php：慢接口的 xhprof/tideways 输出给一下
系统 /linux: dstat 压测下和非压测下的输出给一下，dstat -amsy 1 30

[sarices]

其实很多时候都是数据库问题，试试优化数据库方式着手
还有前端应该上 cdn

[dzdh]

打开 fpmstatus 看看

[redford42]

巅峰时期抓包看一下前端是慢在哪

[LexLuth0r]

现阶段可以考虑用 swoole 扩展一下，推荐 https://github.com/hhxsv5/laravel-s ，高并发还是推荐用 go

[whcoding]

紧急的话可以先加上 https://github.com/hhxsv5/laravel-s 这样可以先抗住了.. 然后再加上缓存尤其是二维码那块

[skymei]

根据你的描述，PHP 应用服务器的问题不大，问题可能出现在前端资源加载和数据库上，前端资源走 cdn ，数据库的 sql 分析一下，应该能找到一些突破点

[icanbeyrhero]

用多台小机器，而不是一台大机器，性能是不是好点？

[yEhwG10ZJa83067x]

带宽没跑满，服务器配置也够，我盲猜数据库吧，慢日志看看卡在哪里了

[barbery]

数据库都跑满了？我怀疑是短链接太多了导致的，建议你开代理池，这个阿里云本身就有的付费项目，减少频繁创建连接，数据库 cpu 下来之后，那剩下的就简单了，横向扩展，动态扩容加应用服务器，动态扩容也是阿里云自带的服务

[yEhwG10ZJa83067x]

@icanbeyrhero #49 是的，不能只是纵向扩展，抗并发尽量横向扩展

[hahasong]

前端资源放到 CDN ，后台上几层缓存，db 查询读缓存，写入放队列慢慢写。再上个容器负载均衡。不信这还扛不住

[ivanfjz]

laravel 虽然慢, 但也没那么差, 个人觉得更大的可能性是数据库的问题
你们既然买了 rds,看下 rds 的性能分析, 看看什么 sql 语句导致的 cpu100%. 数据库慢, 会反向导致 php 服务器卡住爆满崩掉.
如果自己分析不出来, 联系阿里云运维客户, 让他们帮你们分析

[cooper]

跟我们的场景有点像
先上改成 https://laravel.com/docs/9.x/octane ，低版本用 laravel-s ；
数据库改 PolarDB ；
服务器这块改成 K8S 定时伸缩 ，方便还能省不少钱。

[rming]

php 的性能没这么拉吧，问题应该在数据库，前面说的性能优化做到位，数据库缓存读，队列写，合并读写，看下 mysql slow query log 就知道了

[47d7tEUBp521E8fJ]

装个 laravel-s

[rming]

“服务器承载 20%都上不去，但前端页面会变得非常慢”，查一下 LBS 出口带宽，后端机器硬盘读写，fpm slow log, mysql slow log

[thinkwei2012]

1 、先检查数据库日志，定位下慢查询（数据库连接数满）
2 、Nginx 配置检查 gzip 压缩、静态资源过期设置（防止回源问题带来的压力）
3 、php-fpm ，进程静态配置很重要，Opcache 一定要开启来，慢日志问题也要定位解决（查找代码计算量大的问题点）
4 、前端静态资源必上 CDN ，回源 OSS 是最好的

[statumer]

这和 PHP 性能有什么关系？ PHP 这部分 100%是个无状态服务，为什么你们在搞纵向扩展而不是横向扩展？非常令人疑惑。

[awanganddong]

用户端用户注册 //这个没啥好办法，直接数据库硬抗。
进入页面绑定自己身份证号手机号乡镇信息等个人信息 //这个环节加个 redis 队列，异步写入库操作。laravel 还是非常快速支持的。用户同步信息之后，把核心信息写入 redis hash 或者 string 都可以
前端凭借身份证号直接生成个人二维码， //这个环节对后端直接走缓存
向医护人员出示二维码，1 个小时需要做 40 万人口的核酸；//这个地方就完全走 cdn


像这种业务是非常适合引入 redis 这种缓存的。

[minuo0day]

@awanganddong 忘记说了，我们是做了 redis 的

[telun]

数据库都 100%的话肯定不光是 php 这头的问题，查问题先把死锁什么的问题排除吧。
web 端的问题直接 k8s ，硬抗就是了，之后再去慢慢调优，对于高计算量的功能点迁移到函数计算 fc 上去。

[weiwenhao]

检查服务器日志和数据库日志（云服务和 rds 都有监控的）确定一下问题瓶颈是什么
如果是 php 这边的瓶颈： https://learnku.com/laravel/t/24559 （另外最重要的是 opcache ，如果兼容的话最好把 php 版本和 laravel 版本都提升上去）
如果是数据库的瓶颈： 先看慢查询日志，并发查询的语句，检查索引有没有。并发特别高的语句，临时加一个缓存应该也是很快实现的。

话说前端很慢，直接 f12 看看是请求静态资源慢还是请求接口慢呀

[darkengine]

我也觉得瓶颈在数据库，按照你描述的业务，应该会经常访问到重复的数据，加层 redis 吧。

[codespots]

PHP 性能不至于这么拉胯，看看数据库问题，还有前端尽量和服务分开部署在不同服务器上，CDN 赶紧用上，Redis 也加上

[awanganddong]

一般我排查思路是这样的，
首先配置 nginx 日志，
接着就是 shell 脚本对 nginx 超时时间进行排序
查找超时且请求时间比较长的接口，
这时候你就要分析造成这种情况的原因了，
如果可以加缓存的话，就引入缓存，
其实就是查看数据库的查询情况，explain 一波。


一般情况下都是数据库使用不当引起的。
如果没法优化的话，那就稍微花点钱整个数据库主从分离。
服务器也是可以用平台的弹性伸缩。

基本上以上方法用了还不管用，
那就要考虑你们设计有问题了。


像这种业务应该不太会牵扯到多表联查这种情况

[8rmEHZ8WhVHVOb0E]

phper 的话高并发场景可以考虑 webman ，workerman 官方出品 数据库组件直接用的 laravel 的，无缝迁移。

[janda]

框架是没法变的了、只能看看其他方面有没有优化的可能，我们最近也在高并发有些解决方案供参考

- 降低高并发接口与数据库连接
- 添加对应的数据库索引
- nginx 压缩静态资源缓存
- 高并发查询接口使用 redis 等缓存
- 不及时响应数据丢 MQ 慢慢消费
- 前端 cdn
- 集群负载均衡等

例如我们注册的时候是个高并发、但是每次注册前会查询(select)下当前用户是否已注册过！然后在添加(insert)、后来我们就添加唯一索引、不查询，直接添加根据唯一索引的特性来判断最终处理结果、程序捕获异常！

还有一个高并发查询接口也是、因为数据并发没分每秒变动所以、我们用的 redis 缓存设置随机短期时间，但是高并发下会有雪崩穿透击穿的问题

[kakaryan]

你现在做的是对的，先做升级配置的 scale up ，撑着。
为什么卡住原因没有找到，感觉你的压测没有完全实现测试的目标，压测的目标是找到瓶颈点，不是证明你的并发能力。
你在 24 日下午压测，数据库和业务服务器都崩了，那么说明数据库扛不住，因为数据库崩了业务服务器肯定工作不了的。
从你最后压测服务器负载上不去的情况来看，目前瓶颈在数据库上。
是什么业务造成了数据库的压力？是写数据的压力还是读数据的压力？到底是什么动作带来数据库这么大的压力？是不是慢查询？能不能加缓存？是不是要做分库分表？短期内做一些数据完整性上的妥协是不是能快速降低压力？
你们做了压力测试但是没有找到问题，也没有提出解决方案。
从缓解数据库的压力来说，加 redis 做缓存可以快速解决问题但是最好预热数据，否则一到点并发大了依然会崩，最终可能还是要走向 sacle out 的分库分表。

scale up 和压测的路子都是对的，但是问题没找准，解决方案也就出不来。

[awanganddong]

我们虽然调大了服务器的配置，但调大以后压测 10 分钟 20 万人和 4000 医护在线，服务器承载 20%都上不去，但前端页面会变得非常慢，基本上 10 几秒才能打开

关于这点，你们可以把 web 服务器放到单独的服务器上边，前置一个负载均衡，然后你们就查看外网带宽的负载情况，不够就加带宽。然后就是静态资源放到 oss 上边加 cdn 。

尽量把前后端拆分开来，这样的话，职权更清晰，更容易排查问题。

善用日志，负载均衡有日志，第三方 oss 也是有监控日志的，分析下就定位问题了。

[Rache1]

🤦‍♂️ 虽然很多人推荐 laravel-s 和 laravel-swoole ，但是还是鉴于目前的情况不建议赶鸭子上架，后续可以考虑再往这方面靠拢，包括 octane ，赶鸭子上架的话，你可能就有 1+N 个问题了。

现阶段可以根据各方面的慢日志：FPM 、MySQL 、Redis ，以及 Nginx 的日志来分析具体可能是哪些方面导致的问题。

[encro]

阿里云服务器连接数没有改吧，默认 5000 不够，
关键是 redis 和 mysql 要开持久链接。
PHP 一个 fpm 默认只能服务一个请求。

[edk24]

有没有开启 opcache, 这个扩展可以极大的优化性能, 如果是 php-fpm 造成大量占用 cpu 的话可以解决一定的问题

还有 php-fpm 的性能配置, 优化的话可以极大的压榨性能;


接口复杂不, 不复杂其实还蛮推荐用 swoole 重写的, 有数据库连接池, 可以降低 mysql 的压力. 因为每个请求都会生成一个数据库连接. 连接池可以解决这个问题, 速度提升很明显. 少了连接和关闭的操作

---

另一个是 swoole 支持协程, 这个东西也是可以降低数据库压力, 可以让占用数据库连接的时间变短, 提升连接池的复用率

---

慢 sql 要查, 看看有些表字段是不是没加索引, 性能影响很拉胯的

---

redis 集群要用起来, 耗时长的任务不要阻塞等待了, 改成异步查结果. 用 kafka 或者 rabbitmq 做延迟任务处理.

(延迟任务这一块参考支付宝提现, 他会告诉你转账中. 倒计时 5 4 3 2 1, 然后再给你结果)


我能想到只有那么些

[encro]

《解决 nginx+php/java/go/python+mysql 下 time_wait 连接数过多问题》

https://c4ys.com/archives/1609

'enableSchemaCache' => true,
'attributes' => [
PDO::ATTR_PERSISTENT => true,
PDO::ATTR_TIMEOUT => 1,
],

《 php redis 连接数过多解决办法（ Yii,predis,phpredis 等）》

https://c4ys.com/archives/2421

'redis' => [
'class' => 'yii\redis\Connection',
'socketClientFlags' => STREAM_CLIENT_CONNECT | STREAM_CLIENT_PERSISTENT,
],

[encro]

先看数据库 CPU ，
如果数据库 CPU 高，看数据库慢日志并优化索引，
如果数据库压力不高，看 WEB 服务器 PHP-FPM 日志，开启慢日志，优化慢方法，一般是循环太多或者调用第三方接口耗时。
查看连接数，使用持久链接，减少建立链接开销。

[fkdtz]

数据库的 CPU 都打满了？是不是一次性数据量处理太多了，有些数据被重复处理了？

[fkdtz]

在模拟环境装个 APM 看看调用慢在应该能直观反映问题，比如 tideways ，或者基于 tideways 的 php-monitor ，都可以统计出调用栈即调用耗时。

[konakona]

单纯就单体框架的性能排行榜而言，laravel 是几乎垫底的呀。怎么会选择它？ lumen 都好那么一丢丢啊（因为前后分离）。

这种要 swoole 起步。

[fkdtz]

再看下 SQL 慢查呢，既然用了阿里云，他只带有慢 SQL 审计的，后面情况中服务器压测上不去，排除一下 DB 拖慢的可能性。

[konakona]

1. 数据库主从和读写分离，一定要做，可以用现成的云服务（腾讯云有、阿里云也有），只需要在 laravel 的 config/database.php 里配置好，再引入 laravel 支持这样读写数据库的 package （有的，在官网文档里有）就可以运作
2. 做二级缓存，也就是 Redis 或者 Memcache 。
3. Sql 语法优化 —— 之所以提一下是没有必要做。再好的 Sql 语法，在并发到达临界线的时候都会全部卡死。只能重启 mysql 来解决。
4. php-fpm 优化，做静态分配进程数，就是有个配置叫 pm=的那个，根据每个 php-fpm 子线程的占用内存计算出这台电脑最大的 php-fpm 进程数量，然后在 php-fpm 服务启动时就启动着么多个进程，避免使用动态进程过慢引起的并发问题。
5. 做流量负载均衡，做外网访问服务的流量分发。可以用现成的云服务（腾讯云有、阿里云也有）。

6. 改成微服务架构，由于功能没多少，该用 swoole 的同时改成微服务其实很快的。让每个模块独立化运作，由统一的 local gateway 做内网通信分发。

[shot]

> 10 分钟 20 万人和 4000 医护在线
按这个数量级，并发数 1k 都不到，算不上「高并发」。
系统设计的好的话，单机 16C32G 带数据库都能撑住。

不了解 PHP 生态，但是作为一个主流成熟的框架，laravel 不至于连 1k 并发都撑不住。 → 不建议伤筋动骨换开发框架。
---

盲猜这些问题是设计开发没有质量管控，代码堆叠错乱导致的。
临时方案：先上个应用性能监控工具找出性能瓶颈吧，New Relic 或者 SkyWalking 之类，根据监控数据针对性地做优化、测试、压测。
长期方案：建立系统的软件质量管控体系。

[jhdxr]

laravel 现在有自带的 swoole 支持，Laravel Octane 。

数据库那边炸了的话应用服务器的确可能跟着炸（已经进来的请求卡在数据库查询上，还没进来的请求又排着队——你直说做了 LB ，没说限流的话我还是理解成你流量会全量打到应用服务器上的）

『但前端页面会变得非常慢，基本上 10 几秒才能打开』如果已经做了前后端分离，打开依然是白屏的那种慢，考虑上 CDN ，可能是你们的带宽到极限了。没做前后端分离那就要具体分析了，debug tool 看看是卡在 html 的返回（ php 那继续优化，看看啥卡住了），还是前端资源卡住了（参考前后端分离时的方案）

[roundgis]

@minuo0day 還有遞歸？如果可以在中間加 message queue

[micean]

绝对不是 php 的事
cpu 100%是等待数据库的线程积压的结果
1 个小时需要做 40 万人口，平均 1 秒钟也要 111 人，如果一直是单条入库，数据库肯定顶不住
使用批量入库或者用 redis 做中间层

[documentzhangx66]

1.核酸这种系统，居然用 PHP 。

2.应用服务器居然只有 3 台，还是虚拟化的云服务器，而且还只是 32C 64G 。

3.服务器居然也是虚拟化的云服务器，而且只有一台，还只是 32 核 64G 。

求求你们这些官僚资本主义，能放过人民群众吗？那个城市的？我能点举报吗？

[Yunen]

@documentzhangx66 系统竞标 200W ，实际总成本 20W ，人力成本 2W

[guanhui07]

php 用 swoole 罗 ，别用 laravel ，fpm 下 laravel 抗不了 用 hyperf swoft laravel-s 这些依赖 swoole 的 ，常驻内存性能就好很多了，加上协程 类似 golang 了

[LeeReamond]

不是很理解，你们产品上线前没压测吗？自己能提供多少服务没数，为什么会出现生产中业务节点被压力打卦的情况。防火墙和任务队列应该先挂

[rming]

用 laravel 做过并发 2k 的系统，ngx + php + redis + mysql ，需要优化的细节太多，犯错的机会也太多，静态语言确实能够通过编译系统检查和高性能的轮子规避一些问题，但是业务逻辑和程序设计模式的问题，同样也会出现
举个自己的例子，很早之前用 go + opencv 写过一个图片处理的程序，因为当时不熟悉 go 和 cv ，程序性能非常差，后来用 python 重写了，发现 py 有更完善的文档和更成熟应用，更多的社区支持
@documentzhangx66
@shot

[earthyan]

先从 sql 入手吧

[yEhwG10ZJa83067x]

哈哈，OP 空的时候记得 append 分享下最后原因和结果哦，v 友都热情帮你分析了

[mahone3297]

* 阿里云的 rds ，不是有监控么？看看，db 是否有压力（ cpu ，io ）
* db 看有没有慢 sql
* db 没压力的话，ecs 有压力？那就水平扩展？
* 静态资源 cdn

[lmmlwen]

我先收藏一下，手上的项目日活 50w ，使用 php5.5 和 tp3 写的

[DoveAz]

二维码是前端生成的吗

[qbmiller]

1 .这么多地方 都在自建自己的 核酸二维码.... xx 人员也都想自建, 这可是活啊..😋
2. 能上 cdn 都上 ,只是比 oss 多一点成本 . 尤其图片类的,多看看大小
3. 查询那些全上 redis.
4. php 临时换 go java 也来不及, 交钱找 swool 团队看看改造方案

[qbmiller]

小程序不复杂,没几个接口,直接 go java 重写吧,

[imnpc]

这种很大概率是数据库索引有点问题 可以使用 overtrue/laravel-query-logger ，
在本地压测下 ， 看日志里面那些语句执行时间长 ，
优先对查询时间长的对应语句使用下联合索引(复合索引 /混合索引)

[zhuzhibin]

@jhdxr 哥哥，依赖 roadrunner 的 php 版本基本都要 8.0+，如果是旧项目，很难迁移重构的

[imnpc]

另外 Redis 务必使用阿里云的云服务的 不要使用本机自建 因为读写性能受限的