8 核 FrankenPHP 下的 Laravel Octane：压测报告

一、为什么要做这次压测？

FrankenPHP 出来有一阵子了，社区里“跑分”不少，但大多是 Hello World。我一直想知道：

带着这三个问题，我搭了一套完全模拟生产的 8 核环境，硬核绑核压测。数据出来了，结论非常有意思。

为了避免“跑分作弊”，我刻意模拟了真实线上部署。

物理硬件：20 核物理机（但通过 taskset -c 0-7 绑定 8 核，模拟标准 8 核云主机）
服务端：FrankenPHP + Laravel Octane
Worker 数量：8（与 CPU 核心数 1:1 匹配）
压测工具：wrk 绑定 8-15 核（与服务端物理隔离，避免互相干扰）
缓存策略：生产模式（config:cache、route:cache、view:cache 全开）
数据层：
- MySQL：users 表 10 万行真实数据
- Redis：真实连接，模拟缓存读写
- 连表：student（19,261 行） JOIN school（429 行），均走主键索引
压测规则：每场景 20s × 3 次，取中位数

这是本次压测最触目惊心的数据。

结论：少加一个索引，吞吐直接除以 10，延迟乘以 10。

到了 c=500 时，无索引场景的 p99 直接破 1 秒。原因很简单：8 个 Worker 全部被 MySQL 全表扫描阻塞，请求在 PHP 队列里雪崩。线上如果漏一条这样的 SQL，不用等流量高峰，日常用户就能把服务拖死。

观察 /bench/hello：c=100 时 RPS 为 7778，c=500 时为 8035，几乎没涨，但平均延迟从 12ms 飙到了 61ms（5 倍）。

这说明：8 个 Worker 的处理能力已经达到物理极限（CPU/IO 饱和）。 此时增加并发用户数，只会让请求在队列里排队，无法提升吞吐。如果你线上监控发现 RPS 上不去但延迟暴涨，说明 Worker 数量或下游依赖（DB/Redis）已经是瓶颈了。

Redis 场景数据在 3078 ~ 5821 之间大幅摇摆。排查后发现是 Redis 服务端开启了 RDB 快照或 AOF 重写，导致每隔一段时间出现 fsync 阻塞。如果你的 Redis 也有类似波动，建议将 appendfsync 改为 no 或错开重写时间。

按互联网行业惯例：峰均比 = 4，单用户日均请求 15 次（含页面、接口、轮询）。

场景	峰值 RPS	日均 QPS	日总 PV	预估 DAU
纯 JSON 路由	8035	~2009	1.73 亿	~1150 万
Redis 缓存业务	5700	~1425	1.23 亿	~820 万
MySQL 主键查询	5375	~1344	1.16 亿	~770 万
连表复杂业务	4627	~1157	1.00 亿	~670 万
CPU 密集计算	3152	~788	6800 万	~450 万
缺索引（灾难）	556	~139	1200 万	仅 80 万

结论：优化良好的 8 核 FrankenPHP 具备支撑 千万级 DAU 的能力。但若缺一个索引，再好的架构也白搭。

SQL 审查是生死线
EXPLAIN 必须成为 CI 流程的一环。一旦看到 rows > 1000，立即阻塞合并。
Worker 数量 = CPU 核心数（在 8 核下已验证最优）
不要盲目增加 Worker，超过核心数只会增加上下文切换开销，不会提升 RPS。
max-requests 别设 0
建议设为 5000 ~ 10000，防止长驻内存导致的内存泄漏累积（尤其是 Eloquent 缓存和第三方包）。
监控 p99，而不是平均响应时间
压测时 p99 的飙升往往比平均值的缓慢上升能更早暴露队列雪崩和慢查询。
Redis 连接池和持久化策略需要压测验证
不要在压测期间让 Redis 做 RDB/AOF 重写，否则数据会像我的波动一样没法看。