Linux下如何用ab压测Web服务器

本文深入解析了Linux下使用ab命令进行Web服务器压力测试的关键要点与常见陷阱，强调URL必须以斜杠结尾、服务需正常运行且端口配置正确、HTTPS测试依赖OpenSSL支持；指出-c 100 -t 60比-c -n组合更贴近真实负载场景，能有效暴露响应延迟上升和错误率攀升等渐进式问题；并明确只需聚焦“Requests per second”“Time per request (mean)”和“Failed requests”三行核心指标即可快速定位性能瓶颈；同时澄清ab与webbench的本质差异——ab轻量精准，适合作为基准吞吐量的“标尺”，而非替代更复杂的业务级压测工具。掌握这些，你才能用最简单的命令，获得最可靠的性能真相。

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，没这个基线作锚点，全都是空中楼阁。

今天关于《Linux下如何用ab压测Web服务器》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！