Workerman协程压测指标失真主因是协程调度阻塞、连接复用不足及统计口径错位；需通过tcpdump验证真实请求量、禁用同步阻塞调用、统一服务端业务计数与客户端RPS，并监控协程数与内存泄漏。
Workerman协程压测时发现QPS、响应时间、错误率等关键指标与预期严重不符，比如wrk显示10万请求只成功8千，而服务端日志却显示处理了9.5万次——这种数据对不上不是工具问题，而是协程调度、连接复用和统计口径错位导致的。
确认压测工具是否真实发出了目标请求数
先排除“工具没发够”的假象：用tcpdump抓包验证实际网络层流量是否达标。
执行 sudo tcpdump -i any port 2345 -w workerman.pcap（替换为你监听的端口），同时运行wrk命令；压测结束后用Wireshark打开pcap文件，过滤 tcp.len > 0 and ip.dst == 127.0.0.1，统计TCP payload非空的数据包数量。
若抓包数远低于wrk报告的请求数，说明wrk本身因DNS解析失败、连接超时或重试机制失效而未发出全部请求——此时需加 -H "Connection: keep-alive" 并指定 --timeout 30s 避免过早断连。
【关键前提】 必须在压测前关闭系统TCP TIME_WAIT快速回收（sysctl -w net.ipv4.tcp_tw_reuse=1），否则大量短连接会卡在TIME_WAIT状态，导致wrk新建连接失败却不报错， silently drop 请求。
检查Workerman协程内是否发生隐式阻塞
协程压测数据失真，80%源于本该异步的操作被同步调用卡住调度器。
方法一：临时禁用所有数据库/HTTP调用，用 go(function () { usleep(1000); }); 模拟轻量耗时，再压测。若此时QPS恢复稳定，说明原业务逻辑中存在PDO::query()、file_get_contents()等同步阻塞调用。
方法二：在onMessage回调开头插入 var_dump(\Swoole\Coroutine::getCid());，并发1000请求后检查输出的协程ID是否重复出现——如果同一协程ID连续打印多次，证明该协程被阻塞未让出，后续请求被迫排队等待。
注意：不要在协程中使用 sleep()，它会彻底挂起整个Worker进程；必须用 \Swoole\Coroutine::sleep() 或 usleep()（仅限微秒级）。
统一服务端与客户端的统计维度
第一步：确保服务端统计基于实际完成的业务逻辑，而非连接建立数。
在Workerman的onMessage回调末尾添加计数器：$GLOBALS['success_count'] = ($GLOBALS['success_count'] ?? 0) + 1;
并在onClose或定时器中输出该值——这才能反映真实处理完成量。
第二步：关闭Workerman内置的status统计（Worker::$statistics = false;），因其统计的是事件循环收到的fd事件数，包含心跳、空包、重传包，不等于有效业务请求。
第三步：对比wrk的 Requests/sec 和服务端每秒 $GLOBALS['success_count'] 增量，两者差值超过5%即需排查中间件或协议解析层丢包。
若wrk显示1200 RPS但服务端只计数1050，大概率是客户端发送了带\r\n的非法格式数据，被Workerman的Protocol解析器静默丢弃——此时需开启 Worker::$stdoutFile = '/tmp/workerman.log'; 并搜索 bad request 关键字。
验证协程调度器是否被抢占
① 运行压测时执行 watch -n 1 'ps aux | grep "php.*start.php" | grep -v grep | awk "{print \$6}"'，观察每个Worker进程的RSS内存是否持续上涨且不回落——若上涨超过20MB/s，说明协程内存在未释放的资源（如大数组未unset、Redis连接未close）。
② 在onWorkerStart中启动一个独立协程，每秒打印当前活跃协程数：go(function () { while (true) { echo "active coroutines: " . \Swoole\Coroutine::stats()['coroutine_num'] . "\n"; \Swoole\Coroutine::sleep(1); } });
③ 压测期间观察该数值：若长期高于并发数×1.5（例如并发1000却显示2500+），说明协程创建后未正常结束，调度器被大量僵尸协程拖慢。
④ 立即检查代码中所有 go(function () { ... }); 是否都配对了 try { ... } catch (\Throwable $e) { ... }——未捕获异常的协程会直接退出但不释放资源，成为隐形内存泄漏源。
