FPM进程过多，挤爆了CPU，导致短时间内服务器接口迟缓的问题如何解决？

抢购场景200人不一定只有200并发，如果前端不控制点击和刷新频率的话，这点人直接拉高配置就好，前端控制，oss这些做好，还用不上负载均衡。

if (!in_array(rand(100, 200) % 11, [1, 3, 5, 7, 9])) {
            return $this->error("你被挤出队伍了");
        }

试试这个

fpm 的 pm 设置为 static。pm.max_children 设置为CPU核心的两倍。然后如果还是扛不住，建议考虑做弹性伸缩支持，因为你这个其实就是临时性的需求。完全可以通过临时申请服务器来解决问题。

其实PHP 还支持 opcache, DB 持久链接，preload预加载，我觉得你都可以参考下。

php的优化有限。无所谓是代码层和fpm层。除去这两个之外的任何手段，都没用，想都不用想。

• fpm层
  • pm 模式
  • 进程数量
  • opcache (8.x支持jit可以试试）
• 代码层
  • 优化逻辑
  • 减少不必要的网络开销
  • 提前返回

说说swoole
因为laravel的特性，使用swoole，只能每个请求都重新初始化所有的全局对象container、request、response、validate、db等。swoole和opcache的结合没研究过不知道opcache能不能助力swoole，如果不能那每次光文件I/O开销就够一壶了。如果用swoole还是建议使用hyperf等框架

世界加钱可及
在所有的优化手段都应用后还是慢，可以考虑加机器了。一台不够两台，两台不够10台。相信在10台机器都不够的前提下，你一定是不缺钱的。

200 并发 4核8G 应该是扛不住的，你可以试试修改 php-fpm.conf 改成 static，但不一定管用，如果是到点抢购，可以用云平台的弹性伸缩+负载均衡，直接镜像你原来的服务器，操作起来很简单，就注意点如果数据库和 redis 在原服务器存储，弹性服务器一定要写成主服务器的 ip。

2. 可以把并发接口单独部署在 laravels 博客：记使用 Laravel-s 抵御百度爬虫的经历
3. 是否提升服务器的配置，在于平时情况避免浪费

在 Laravel 框架中，当多个请求同时访问控制器的方法时，FPM（FastCGI Process Manager）的 CPU 资源占用率会根据请求的复杂度和数量以及服务器的配置情况而异。因此，无法确定 FPM 在并发访问时的 CPU 资源占用率会是多少，也不能保证它不会爆满。通常情况下，为了避免 FPM 占用过多 CPU 资源，应该尽量减少对控制器方法的并发访问，或者通过优化服务器配置来提高 FPM 的处理能力。

换webman吧

升到php8+lv9+octane(swoole)，你的单机还可以继续战斗。。

有没有可能。。你的瓶颈是mysql。。不是php

从你的问题来看的话，目前感觉就是php-fpm过多，CPU占用率高，但是包括其他指标都没有提供，有点难看出瓶颈 首先建议，先把php-fpm进程改成static，数量一般都是64左右，开opcache，再重新压测下看看吧

可以尝试一下升级 php8.1, 开启Jit，个人并发自测过，有倍数级的并发提升。

1. 生产环境建议把redis mysql独立出去 一般情况都是买的rds
2. php-fpm环境调优无非就是: 框架本身的缓存(配置、路由、自动加载)，fpm、opcache配置这一块的还是很重要，可以看下相关资料
3. 看评论区有的朋友提到swoole，重构代价很大，不过可以将部分业务独立出去 用swoole来做，我司早上某个时间点高峰期(同时1000左右吧)某个模块也是采用swoole来做的api，稳定运行几年了 整个项目架构: 能异步就异步，能分离就分离

使用Laravel Octane，带宽拉高，我觉得不使用Laravel Octane或swoole，拯救不了，除非堆配置

php 如果是 fpm 模式选框架还是 phalcon 这种扩展性的香，laravel什么优雅纯粹扯犊子

先把各种缓存加了吧，比如opencache，不行直接上webman，composer装过去无缝

把抢购服务单独拉出来用swoole做服务端处理高频请求。 原来的业务结构不变。

令牌桶 + 按照用户账号加锁 控制下进入的用户，限制每个用户ID 进入controller次数

升级服务器配置 完美解决