webman压测前必须确认三项启动状态：ps aux查至少两个worker进程、netstat查端口处于listen状态、健康路由返回200且含x-powered-by头，缺一不可。
Webman压测前必须确认的三个启动状态
压测结果失真，八成是因为服务没跑在预期模式下。Webman不是“启动了就行”，它依赖常驻内存和事件循环，一旦启动异常，就退化成比FPM还慢的伪异步。
检查这三项，缺一不可：
-
ps aux | grep webman看到至少两个worker进程（主进程 + worker），且start.php start -d后无报错退出 -
netstat -an | grep :8787（或你配置的端口）确认端口处于LISTEN状态，而非CLOSE_WAIT或未监听 - 访问
http://localhost:8787/health（或自定义健康检查路由）返回 200，且响应头中含X-Powered-By: webman
常见错误是用 php start.php start 前台运行后直接关终端，导致进程被 SIGINT 终止；或 config/bootstrap.php 中误写了阻塞式 sleep(1)，卡死事件循环。
wrk压测时并发数与线程数的配比陷阱
wrk 的 -c（连接数）和 -t（线程数）不是随便填的。设得不合理，测的不是 Webman，而是你本地机器的 TCP 连接调度能力。
真实建议值（基于 4 核 8G Ubuntu）：
- 测 QPS 上限：用
wrk -t8 -c4000 -d60s http://localhost:8787/api/test，-t不超过 CPU 核数，-c可设为-t * 500起步，逐步加到 8000 观察拐点 - 测稳定性：用
wrk -t4 -c1000 -d120s --timeout 5s http://localhost:8787/api/test，重点看Errors是否突增、P99是否跳变 - 绝对不要用
-t1 -c10000—— 单线程根本发不出万级并发，wrk自身会成为瓶颈，数据毫无参考价值
你看到的 “Webman QPS 降了”，大概率是 wrk 在重试超时连接，而不是 Webman 处理不过来。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
数据库查询压测必须用异步驱动，否则白测
Webman 的 I/O 并发优势，只在真正异步时生效。如果控制器里写 Db::table('user')->find(1)，背后仍是同步 PDO，一个请求卡住，整个 worker 就停摆 —— 此时它和 FPM 没本质区别，只是少了一次 autoload 开销。
要测出真实差距，必须：
- 启用
workerman/mysql异步客户端，替换默认 PDO - 控制器中改用
AsyncMysql::get()或封装好的协程查询方法 - 确认 MySQL 的
max_connections≥ Webmanworker_num * 2，否则连接池抢不到连接，大量请求挂起在Connecting状态
实测中，同一接口用同步 PDO 时 Webman QPS 仅比 FPM 高 1.2 倍；换异步驱动后跃升至 5.8 倍 —— 差别不在框架，而在你有没有把“异步”落到实处。
对比 Laravel/RoadRunner 时最容易忽略的内存泄漏点
很多人压测 Webman vs Laravel+RoadRunner，发现 Webman 内存缓慢上涨，就断言“不如 RoadRunner 稳定”。其实问题常出在日志、缓存或 ORM 实例没做连接复用。
典型泄漏源：
- 每个请求 new 一个
Redis实例，而不是从ConnectionPool获取 - 日志组件（如 Monolog）未配置
RotatingFileHandler，单个日志文件暴涨到 GB 级，触发系统 swap - 中间件中用了静态变量缓存大数组，但没清理逻辑，随请求数线性增长
验证方式很简单：watch -n 1 'ps aux --sort=-%mem | head -5' 压测 10 分钟，看 Webman worker 进程 RSS 是否持续上升。如果是，先查 app/middleware/ 和 app/service/ 下有没有 new 对象却没释放的代码 —— 架构再先进，也扛不住裸写内存泄漏。
