ab 命令需确保url以/结尾、服务已启动且端口正确、https需openssl支持；推荐用-c 100 -t 60替代-c -n组合；关键看requests per second、time per request(mean)和failed requests三行。
ab 命令怎么写才不报错
直接运行 ab -c 100 -n 1000 http://localhost/ 很可能失败，常见报错是 Connect to server failed. Aborting benchmark.。这不是 ab 本身坏了，而是你漏了几个硬性前提：
- URL 必须以
/结尾（比如http://localhost/可行，http://localhost大概率失败） - 目标服务必须已启动且监听在对应端口（默认 80 或 443；若用 Nginx/Apache 但改过端口，得显式写
http://localhost:8080/） - HTTPS 测试需确保 OpenSSL 支持，且 URL 写成
https://开头；否则会卡在 SSL handshake 阶段
并发数和请求数到底怎么配
-c 和 -n 看似简单，但乱设会导致结果失真或测不出真实瓶颈：
-
-c 500 -n 500表示“发起 500 次请求，最多同时发 500 个”，实际是瞬间打满——适合测连接建立能力，但掩盖了持续负载下的内存/CPU 泄漏问题 -
-c 100 -t 60（用-t代替-n）更贴近真实场景：每秒稳定发约 100 个请求，持续 60 秒，能暴露响应延迟上升、错误率爬升等渐进式问题 - 别盲目堆高
-c：Linux 默认的net.core.somaxconn和fs.file-max限制下，-c > 1024很可能触发socket: Too many open files，得先调系统参数
看懂 ab 输出里真正关键的三行
ab 的输出有二十多行，但只需盯死这三行就能判断是否压出问题：
-
Requests per second:—— 实际吞吐量，不是你设的-c值。如果远低于预期（比如设了-c 200却只跑出 30 req/s），说明后端已卡死或网络受限 -
Time per request:后面带(mean, across all concurrent requests)的那个值 —— 这才是用户感知的平均响应时间。注意它和Transfer rate:无直接关系，慢未必是带宽问题，可能是 PHP 进程阻塞或 DB 查询慢 -
Failed requests:和Connect failed数量 —— 一旦非零，优先查服务日志（如 Nginx 的error.log），而不是调 ab 参数；90% 是后端拒绝连接或超时，不是 ab 不够快
ab 和 webbench 别混着用
很多人想“多试几个工具比一比”，但 ab 和 webbench 定位完全不同，强行对比会误导结论：
-
ab是单进程、阻塞式 HTTP 客户端，模拟的是“一个用户疯狂刷新”，适合测单点接口极限，但无法模拟真实浏览器行为（如 Cookie 复用、多资源并行加载） -
webbench是多进程 fork 模型，能撑到 3 万并发，但只统计页面级指标（pages/min），不提供每个请求的延迟分布，也压不出长连接复用场景的问题 - 真正要验证线上稳定性，
ab只该用作快速冒烟测试；复杂业务链路（登录→下单→支付）得换locust或jmeter，它们支持 session 管理和事务控制
ab 的价值不在“最强”，而在“最轻、最快、最准”——只要 URL 对、参数对、后端活着，它返回的 Requests per second 就是当前配置下最干净的吞吐基线。其他工具再 fancy，没这个基线作锚点，全都是空中楼阁。
