Swoole性能测试工具入门指南

本文深入剖析了Swoole高性能服务压测的常见误区与实战优化要点，直击“QPS虚低”的根源——并非Swoole本身性能不足，而是测试工具配置不当（如ab未加-k启用长连接）、服务端冗余开销（如开启gzip、滥用write()、debug模式未关闭）、环境限制（ulimit-n不足、内核参数未调优）及监控误判（依赖top而非Swoole::stats()）所致；文章强调必须使用专业压测工具（wrk/JMeter）、严格遵循长连接规范、精简启动配置、合理设置worker数，并以Swoole原生统计指标为唯一可信依据，为开发者提供了一套可立即落地、效果显著的性能调优闭环方案。

很多人一上来就用 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 反而因调度争抢下降

本篇关于《Swoole性能测试工具入门指南》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！