ab工具必须加-k参数启用长连接，否则因短连接开销导致QPS虚低；Swoole服务端需关闭gzip、避免onRequest中write()、ulimit-n≥65535；推荐wrk或JMeter压测，禁用curl/Python自写脚本；监控以Swoole::stats()为准；编译和启动阶段需关闭debug、xdebug及无用回调，worker_num设为物理核心数。
ab 工具够用，但必须加 -k 参数，否则测出来全是假低分
很多人一上来就用 ab -n 10000 -c 100 http://127.0.0.1:9501/，结果 QPS 只有几百——不是 Swoole 慢，是你在反复建连、挥手、TLS 握手。HTTP 短连接的开销远大于业务本身，尤其在高并发下，内核 TIME_WAIT 和端口耗尽会直接拖垮结果。
正确做法只有一条：强制长连接。
-
ab -n 10000 -c 100 -k http://127.0.0.1:9501/（-k启用 KeepAlive） - 服务端
Swoole\Http\Server必须关闭gzip（设'http_compression' => false），否则 CPU 被压缩吃满，QPS 虚低 - 避免在
onRequest里调用$response->write()，ab不支持 HTTP chunked 编码，会报错或截断 - 测试前确认
ulimit -n≥ 65535，不然客户端连不上 1000+ 并发就卡住
别用 curl 或手工写脚本压测
单个 curl 是阻塞的，写 for 循环起 100 个进程？那测的是你 shell 的 fork 效率，不是 Swoole 的吞吐。更糟的是，没做连接复用、没控并发节奏、没统计响应时间分布，数据完全不可比。
真实压测要满足三个条件：固定并发数、稳定请求节奏、可重复采样。所以必须用专业工具。
-
wrk最轻快：wrk -t4 -c400 -d30s http://127.0.0.1:9501/（4 线程、400 连接、30 秒） -
JMeter适合带参数、登录态、多步骤场景，但 GUI 启动重，别在压测机上跑 GUI - 绝对不要用 Python 的
requests+threading自己拼——默认不复用连接，且 GIL 会让并发数严重注水
Swoole\Server::stats() 是唯一可信的实时指标源
别信 top 里的 CPU%，也别信 ps aux 看的内存——Swoole 的 worker 是常驻进程，内存常驻不释放是正常行为。真正要看的是它自己暴露的运行时状态。
- 在任意回调里调用
$server->stats()，返回数组含connection_num、accept_count、close_count、tasking_num等 - 如果
accept_count增速远低于你发的请求数，说明连接被拒绝了（max_connection不够或ulimit卡死） - 如果
tasking_num持续 > 0，而任务迟迟不finish，大概率是 task_worker 里写了同步阻塞操作（比如sleep()、file_get_contents()） - 注意：该方法返回的是当前 worker 进程视角的数据，不是全局总和（多 worker 下需汇总）
编译和启动阶段就埋下的坑，测试时才爆发
很多“性能差”问题，其实在你敲下 php server.php 那一刻就决定了。debug 模式、未关日志、错误回调空挂，全都会吃掉 20%+ 吞吐。
- 编译 Swoole 时务必加
--enable-swoole-debug=no，并用gcc -O2优化 - PHP 启动参数禁用
xdebug、opcache.enable_cli=0（CLI 模式下 opcache 默认关） - 代码里删掉所有没用的回调，比如没逻辑的
onConnect、onClose—— 每次触发都多一次 PHP 函数调用开销 - worker 数设为物理核心数（非超线程数），
'worker_num' => 8在 8 核机器上合理；设成 16 反而因调度争抢下降
ulimit -n 和 net.core.somaxconn，再调 worker_num，最后动业务代码。 
