先确认ab是否安装及是否在path中：centos/rhel装httpd-tools，debian/ubuntu装apache2-utils；若which ab无输出，需重装或手动添加/usr/bin到path。
ab 命令没找到？先确认安装路径和依赖
直接运行 ab 报 “command not found”，不是没装对，就是装了但不在 $PATH 里。CentOS/RHEL 系统装的是 httpd-tools 包，Debian/Ubuntu 是 apache2-utils，Arch 则是 apache 整体包——但注意：它只带 ab，不带 httpd 服务本身。
验证是否可用，执行：
which ab
如果没输出，说明命令不可见。常见做法是：
- 重装并确认包名正确：
yum install -y httpd-tools（CentOS 7/8）或dnf install -y httpd-tools（CentOS Stream / RHEL 9） - Debian/Ubuntu 用户检查是否误装了
apache2（这是服务端），应改用：apt install -y apache2-utils - 装完仍不可用？手动加路径：
export PATH="/usr/bin:$PATH"（多数发行版ab在/usr/bin/ab）
GET 请求压测：-c 和 -n 怎么配才合理
并发数（-c）和总请求数（-n）不是越大越好。盲目设 -c 1000 -n 100000 很可能卡在本机 TCP 连接耗尽，而非压出服务器瓶颈。
真实场景建议从低往高试探：
- 先跑
ab -c 10 -n 100 http://example.com/，看是否稳定、有无超时或连接拒绝 - 逐步提升
-c：20 → 50 → 100，每次观察Failed requests和Connect failed是否突增 - 若
Connect failed频繁出现，说明压测机本地端口耗尽或内核限制过严，需调/proc/sys/net/ipv4/tcp_tw_reuse和net.core.somaxconn -
-n建议 ≥ 1000，否则统计结果抖动大；但别设成几百万——ab是单线程发请求，纯靠复用连接，大数量下耗时主要在本机调度
POST 接口测试：-p 和 -T 必须成对出现
想测登录、下单这类接口，光写 -p postdata.txt 不生效，ab 默认按 text/plain 发，而绝大多数后端只认 application/x-www-form-urlencoded 或 application/json。
必须显式指定 -T，否则后端收不到参数，返回 400 或空响应：
ab -c 20 -n 500 -p ./login.json -T "application/json" https://api.example.com/login
注意几个易错点：
-
postdata.txt文件末尾不能有多余换行，否则某些服务会解析失败 -
-T的值要和后端实际接受的Content-Type完全一致，大小写敏感（如application/json≠Application/Json） - 若接口需要 Cookie 或认证头，用
-C "sessionid=abc123"或-H "Authorization: Bearer xxx" - 不要用
-p传二进制文件（如图片），ab不做编码处理，会乱码
结果怎么看？重点关注这三项指标
ab 输出几十行，真正决定服务器抗压能力的就三个数字：
- Requests per second：吞吐量，单位是 req/s。它受服务器 CPU、IO、数据库连接池等共同制约，是核心性能标尺
-
Time per request (mean)：平均延迟，注意看括号里是
(across all concurrent requests)还是(mean across all requests)——前者才是你该盯的，它反映并发下的真实响应毛刺 -
Percentage of the requests served within a certain time (ms)：比如
90%，说明大部分用户感知尚可；若 <code>50%>1000ms，说明已有明显排队或锁竞争
容易被忽略的是 Failed requests 下的子项：Connect failed 是压测机问题，Receive error 多是服务端主动断连（如 Nginx 的 proxy_read_timeout 触发），Length mismatch 则大概率是后端返回内容长度与 Content-Length 不符——这些都不是服务器“扛不住”，而是配置或协议层面没对齐。
