ab不适合webman高并发压测，因其默认不复用连接、每次新建tcp连接导致端口耗尽和time_wait堆积，无法体现webman事件驱动与连接复用优势；实测加-k后qps提升超65%，且ab不支持http/2、行为模拟弱、指标单一；wrk和k6更匹配，前者支持连接复用与多线程，后者可阶梯压测并联动监控定位真实瓶颈。
Webman压测不能只看ab跑出的数字，它本质是常驻内存+事件驱动模型，用错工具或参数会严重低估真实能力。
为什么ab不适合Webman高并发压测
ab默认不复用连接，每次请求都新建TCP连接，这会快速耗尽本地端口、触发TIME_WAIT堆积，且无法体现Webman在长连接下的复用优势。实测中，ab -n100000 -c200（未加-k）在Webman上QPS比加-k低65%以上，延迟波动剧烈，错误率虚高。
- 它不支持HTTP/2，无法测试Webman对现代协议栈的适配能力
- 无法模拟真实用户行为（如鉴权Token轮换、参数随机化）
- 输出指标单一，缺少P99/P999延迟、错误分布、连接建立耗时等关键维度
wrk是Webman压测的首选命令行工具
wrk基于epoll/kqueue，支持连接复用、多线程、Lua脚本扩展，与Webman底层I/O模型更匹配。官方基准测试和多数生产验证均采用它。
- 必须加
-k启用keep-alive，例如：wrk -t4 -c1000 -d60s --timeout 10s -k http://localhost:9501/api/user?id=123 - 用
--latency开关开启详细延迟统计，否则默认只显示平均值 - 若需带Header（如JWT），用
-H "Authorization: Bearer xxx"，避免写脚本绕过 - 注意
-c值不要超过服务端worker_num× 1024（单Worker最大连接数），否则客户端先扛不住
用k6做阶梯式压测与稳定性验证
当需要观察Webman在流量爬升过程中的拐点（如连接池打满、内存缓慢泄漏、P99突增），k6比wrk更可靠。它能精确控制RPS增长节奏，并内建指标聚合。
- 写一个
script.js，用http.get()发起请求，check()校验状态码和JSON结构 - 执行
k6 run -u 100 -i 300 script.js（每秒100个虚拟用户，持续300秒） - 配合
--out influxdb=http://localhost:8086推指标到InfluxDB，查CPU/内存/连接数是否线性增长 - 特别注意
http_req_failed和http_req_duration的P95曲线，它们比平均值更能暴露Webman在高负载下的调度抖动
别忽略服务端监控联动
压测工具只告诉你“结果”，但不告诉你“为什么”。Webman启动后，php start.php status输出的connections、requests、memory_usage必须和压测数据同步比对。
- 如果
wrk显示QPS卡在8000，但status里connections始终低于200，说明是客户端瓶颈或网络丢包，不是Webman问题 - 若
memory_usage随时间持续上涨，即使没OOM，也要检查是否有闭包引用、全局数组未清理、Redis连接未释放 - Webman日志里出现
WARNING: connection pool is full，意味着数据库连接池配置（max_connections）已成硬限，此时调大worker_num无用
真正卡住Webman性能的，往往不是框架本身，而是连接池大小、Redis超时设置、MySQL慢查询、或是PHP OPcache未启用——这些细节在压测报告里不会自动标红，得自己盯着status和top交叉看。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
