swoole 4 自带的 benchmark/run.php 是专为验证其网络模型设计的轻量级工具，不支持 http 完整语义，不可对标 wrk 或 ab；真实性能评估须在统一环境、相同业务逻辑、关闭干扰项下横向对比，否则数据无参考价值。
直接说结论：Swoole 4 自带的压测工具（benchmark/run.php）不是用来对标 wrk 或 ab 的通用压测器，而是专为验证 Swoole 网络模型设计的轻量级验证工具；真实性能评估必须在统一环境、相同业务逻辑、关闭干扰项的前提下做横向对比，否则数据无参考价值。
压测工具选型要分清用途
Swoole 提供的 run.php 是基于 swoole_client + pcntl 的多进程同步压测脚本，特点是：
- 只支持 TCP/UDP/WebSocket 等底层协议，不支持 HTTP/HTTPS 完整语义（比如 chunked 编码、重定向、Cookie 管理）
- 适合验证 Swoole Server 的连接吞吐、短/长连接稳定性、协程调度开销
- 不适用于 Web API 场景的端到端性能评估（缺少 header、body、状态码校验等）
- 异步版
async.php可支撑更高并发，但依然不具备请求编排、断言、分布式协调能力
做有效基准测试的硬性条件
所有压测结果失真的主因，往往来自环境或配置失控。Swoole 4 的性能释放依赖以下关键控制点：
- 编译时禁用 debug：
--disable-debug --enable-swoole --enable-openssl，并启用-O2优化 - 运行时不输出任何内容到 stdout/stderr（包括
echo、var_dump、错误日志），否则会阻塞事件循环 - 开启端口复用（
enable_reuse_port => true），尤其在多 worker 场景下避免 TIME_WAIT 瓶颈 - HTTP Server 关闭 gzip、关闭 access log、禁用未使用的回调（如
onConnect、onClose） - 使用
SWOOLE_BASE模式替代默认的 reactor-thread 模式，减少 IPC 开销
横向对比必须对齐维度
不同框架/语言的 QPS 数值不能直接比大小。例如一份常见误判：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 用 ab 测 Swoole HTTP Server（含路由、响应封装） vs 用 go http.ListenAndServe（裸响应）——本质不公平
- 未开启 keep-alive 的短连接测试，会放大网络握手开销，掩盖真实处理能力
- Worker 进程数设为 1 却和 Golang 多 goroutine 并发比吞吐——相当于拿单车道比八车道
- Redis 查询未共用同一实例、延迟不稳，导致 I/O 成为瓶颈而非 CPU 或协程调度
推荐做法：固定硬件（如 4C8G）、固定压测工具（wrk + -d 60s -c 1000）、固定业务逻辑（Redis GET + JSON 返回）、固定连接模式（-H "Connection: keep-alive"），再跑三轮取中位数。
性能表现的实际参考区间
在规范配置下，Swoole 4（PHP 8.2+）典型 HTTP 接口的实测范围（单位：QPS）：
- 纯 echo 响应（无 IO）：7–12 万（worker_num=CPU 核数，启用 reuse_port）
- 单次 Redis GET（本地，1ms 延迟）：2.5–4.5 万
- 简单 MySQL 查询（PDO 长连接）：1.2–2.0 万
- 带 JWT 解析 + 权限校验：8–15 千
这些数值会随 PHP 版本、Swoole 编译选项、内核参数（如 net.core.somaxconn）明显浮动，仅作趋势锚点，不可照搬。
