Workerman最大连接数由Worker::$maxConnections和系统fd上限共同决定；ab因短连接模型无法测出真实长连接上限，需用支持复用的客户端（如Workerman benchmark）验证。
Workerman 的最大连接数不是“测出来”的，而是由 Worker::$maxConnections 配置和系统文件描述符（fd）上限共同决定的；盲目压测只会卡在 Too many open files，却看不出哪一层真瓶颈。
为什么 ab 压不出真实最大连接数？
ab 每个请求都新建+关闭 TCP 连接，本质是短连接模型，它根本不会维持长连接去“占满” Workerman 的连接池。你用 ab -c 5000，实际看到的是 5000 个瞬时并发连接建立/断开，不是 5000 个存活长连接。
- ab 报
socket: Too many open files—— 这是 ab 自身客户端 fd 耗尽，和服务端无关 - ab QPS 上不去但 CPU 很低 —— 瓶颈在三次握手、TIME_WAIT 和端口耗尽，不是 Workerman 处理能力问题
- 即使 Workerman 设了
$worker->maxConnections = 100000，ab 也永远达不到这个数，因为它不复用连接
真正验证长连接上限：用自建客户端脚本 + lsof 观察
要确认 Workerman 能稳定维持多少个长连接，必须用能复用连接的客户端，一边建连一边观察 fd 占用：
- 用 PHP 的
stream_socket_client或 Python 的websockets库，循环创建连接并保持不关闭 - 每建 100 个连接，执行一次
lsof -p <pid> | wc -l，对比cat /proc/<pid>/limits | grep "Max open files" - 当
lsof数值逼近Max open files的 soft limit 时，新连接就会静默失败（无日志、无报错、只卡在 SYN_RECV） - 此时减去定时器、日志、Redis 连接等开销，剩下的才是可用长连接数
推荐压测工具：按场景选，别迷信 ab
ab 只适合 HTTP 短连接基础连通性验证；Workerman 长连接、WebSocket、TCP 场景必须换工具：
-
Workerman 自带
benchmark：支持长连接、自定义协议帧、连接复用，结果最贴近真实业务，路径在Workerman/bin/benchmark -
JMeter + WebSocket Samplers 插件：适合 WebSocket 集群压测，需配
WebSocket Open Connection（勾选 Streaming Connection）+WebSocket Request-Response Sampler -
自写 PHP 客户端：用
stream_socket_client控制超时、重试、连接池大小，逻辑透明，调试方便 - 避免用 Locust 或 Artillery 做长连接压测——它们默认每请求建新连接，除非手动管理 session，否则和 ab 一样无效
最容易被忽略的一点：改完 /etc/security/limits.conf 或 systemd 的 LimitNOFILE 后，必须完整 stop 再 start Workerman 进程；reload 不会重新加载 fd 限制，所有压测都白跑。
