ab无法准确测试Swoole并发能力，因其单线程、select/poll模型与Swoole的epoll异步机制不匹配；JMeter需调优参数避免自身成瓶颈；wrk+Lua脚本才是最适合Swoole的压测方案。
ab 不能测 Swoole 的真实并发能力，JMeter 更接近实际，但两者都容易误判瓶颈位置。
ab 对 Swoole 压测结果严重失真的原因
ab 是单线程发包、多连接复用模型，它内部用 select/poll 管理连接，无法真正模拟高并发下 TCP 连接建立、TIME_WAIT、连接池复用等行为。Swoole 是基于 epoll 的全异步事件驱动，ab 的请求压过去时，往往还没触发 Swoole 的 onReceive 回调，就已经被 ab 自身的 socket 缓冲区或系统 net.core.somaxconn 限制住。
-
ab -c 1000看似并发 1000，实际在 Linux 上可能只发出几百个有效 SYN 包，其余排队或超时 - Swoole 启用了
so_reuseport或协程 HTTP 服务器时，ab 完全感知不到连接复用和协程调度优势 - ab 不支持 keep-alive 持久连接的细粒度控制（比如每连接发多少次请求），而 Swoole 的性能恰恰依赖长连接复用
- ab 统计的
Requests per second是总请求数 / 总耗时，掩盖了请求毛刺、延迟尖峰，对 Swoole 的协程切换抖动不敏感
JMeter 测试 Swoole 时必须调整的关键参数
JMeter 虽然能开多线程、支持 JSON/Token/CSV 参数化，但默认配置仍会拖累 Swoole 表现——尤其当压测机本身资源不足时，JMeter 反而成了瓶颈。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 线程组里必须关掉
Use KeepAlive外的「Retrieve All Embedded Resources」，否则会额外发起 CSS/JS 请求，干扰主接口指标 - JMeter 的 HTTP 请求默认启用
Redirect Automatically，若 Swoole 接口返回 302，会导致线程卡住或统计错乱，应手动关闭 - 建议用
jp@gc - Ultimate Thread Group替代原生线程组，可阶梯加压，避免瞬间打爆 Swoole 的max_coroutine - 监听器只保留
View Results in Table和Backend Listener（写入 InfluxDB），禁用Aggregate Report图形界面——GUI 渲染本身吃 CPU - 压测机 JVM 参数至少设为
-Xms2g -Xmx2g -XX:+UseG1GC，否则 GC 暂停会污染响应时间数据
真正适合 Swoole 的压测组合：wrk + 自定义 Lua 脚本
ab 太老，JMeter 太重，Swoole 的协程 HTTP 服务需要能精准控制连接生命周期、支持 pipeline、可嵌入业务逻辑的工具。wrk 是目前最匹配的选择。
-
wrk -t 4 -c 400 -d 30s --latency http://127.0.0.1:9501/api/test中的-c是连接数，不是并发线程数，更贴近 Swoole 的连接池语义 - 用 Lua 脚本能构造真实业务场景：比如先 POST 登录获取 token，再带 header 发起后续请求，
wrk会复用连接并维持 session - wrk 默认启用 HTTP/1.1 pipeline，可测试 Swoole 的
http_compression和buffer_output_size配置效果 - 注意 wrk 不校验 HTTPS 证书，若 Swoole 开了 TLS，需加
--sni-name和--cafile参数，否则握手失败率飙升
别迷信 ab 的“简单”或 JMeter 的“全面”，Swoole 的性能拐点常出现在 max_coroutine、reactor_num、TCP backlog 和内核 net.ipv4.ip_local_port_range 的交叉处——这些地方，只有你把 wrk 的连接分布、系统 netstat 输出、Swoole 的 swoole_server->stats() 三者对齐，才能看清真实瓶颈在哪。
