ab 是 Apache HTTP Server 项目自带的压力测试工具，主要用于评估 Web 服务器在不同负载下的响应能力，适合在测试环境摸底服务器性能。
先说结论：ab 工具轻量便携，能对 Apache、Nginx、Tomcat 等多种 Web 服务器进行并发压力测试，但需注意避免在生产环境直接施加过高负载，且单机 ab 存在并发上限，高 QPS 场景需分布式压测。
- 适合：本地或测试环境快速验证服务承载能力，定位响应时间和吞吐量瓶颈。
- 先准备：确认已安装 httpd-tools 或 apache2-utils 包，并掌握基础参数如 -n 和 -c。
- 再验证：测试后重点观察 Requests per second 和 Failed requests 指标，结合服务器资源监控分析。
- 防误判：监控压测机自身 CPU，若压测机满载则结果无效。
命令速用版
以下命令可用于快速发起一次基础压力测试，向目标地址发送 1000 个请求，并发数为 100：
ab -n 1000 -c 100 http://localhost/
若需测试 POST 请求，可配合 -p 参数指定数据文件，并使用 -T 设置 Content-Type：
ab -n 500 -c 50 -p data.json -T "application/json" http://example.com/api
工作原理与风险
ab 的工作原理是创建多个并发访问线程，模拟多个访问者同时对某一 URL 地址进行访问。它既不会占用很高 CPU，也不会占用很多内存，但会给目标服务器造成巨大的负载，其原理为高并发请求模拟，需严格控制测试范围。通过记录每个请求的响应时间和服务器返回的状态码，ab 能计算出请求的平均响应时间、服务器的吞吐率等重要性能指标。
注意：ab 是单进程工具，受限于单机文件描述符和网络栈能力。若测试目标预期 QPS 过高（如超过 10k），单机 ab 可能先于服务端成为瓶颈，导致测试结果偏低。此时应考虑使用分布式压测或多台机器同时发起测试。
分步处理
1. 安装工具
在大多数基于 Debian 或 Ubuntu 的 Linux 系统中，可使用以下命令安装：
sudo apt-get update sudo apt-get install apache2-utils
对于基于 Red Hat 或 CentOS 的系统，则需使用 yum 命令：
sudo yum install httpd-tools
安装完成后，可通过执行 ab -V 命令来验证是否安装成功，若安装无误将输出版本信息。
2. 执行测试
打开命令行终端，导航至包含测试脚本的目录（如有），执行 ab 命令。注意测试目标是基于 URL 的，既可以用来测试 Apache 的负载压力，也可以测试 Nginx、Lighttpd、Tomcat、IIS 等其它 Web 服务器的压力。
3. 监控资源
测试时通过 top、vmstat 等观察 CPU、内存、磁盘 I/O，确保测试机本身不是瓶颈。
客户端性能瓶颈排查
在使用 ab 进行测试时，压测机自身性能不足是导致结果误判的常见原因。若出现以下情况，说明瓶颈可能在客户端：
- 现象：ab 输出的 Requests per second 较低，但服务端资源（CPU、内存）利用率很低。
- 排查：在运行 ab 的终端另开窗口，使用 top 命令观察 ab 进程的 CPU 占用率。
- 判断：若 ab 进程 CPU 占用持续接近 100%，说明单机并发能力已达上限。
- 解决：降低并发参数 -c，或增加压测机器数量进行分布式测试。
瓶颈类型与指标对照表
测试结束后，ab 会输出统计报告。单纯看 ab 数据不足以定位问题，需结合服务端监控指标（如 top、iostat）进行综合判断：
| ab 指标表现 | 服务端监控表现 | 可能瓶颈 | 排查方向 |
|---|---|---|---|
| Requests per second 低 Time per request 高 | CPU 使用率高（user/sys） | 应用计算瓶颈 | 检查代码逻辑、算法复杂度、是否频繁序列化 |
| Requests per second 低 Time per request 高 | CPU 等待高（wa%） | 磁盘 IO 瓶颈 | 检查数据库慢查询、磁盘读写负载、日志写入 |
| Requests per second 低 Time per request 高 | 内存使用率高，Swap 交换频繁 | 内存瓶颈 | 检查内存泄漏、缓存配置、增加物理内存 |
| Failed requests 非零 Connection timeout | 网络丢包或带宽满载 | 网络带宽瓶颈 | 检查网卡流量、带宽限制、防火墙策略 |
| Requests per second 低 | 服务端资源空闲 | 客户端瓶颈 | 检查压测机 CPU、文件描述符限制（ulimit） |
常见错误码排查
测试过程中若出现错误，可参考以下排查步骤：
- Socket error: Too many open files
原因：压测机或服务端文件描述符限制过低。
排查：执行ulimit -n查看限制，临时调整为ulimit -n 65535。 - Connection refused
原因：服务端未启动、端口错误或防火墙拦截。
排查：执行netstat -tulpn | grep 端口确认服务监听状态，检查 iptables 或安全组规则。 - Timeout 或大量 Failed requests
原因：服务端处理过慢或网络不稳定。
排查：结合上述瓶颈对照表，检查服务端日志（如 access.log、error.log）确认是否有 500/502/504 错误。
常见坑
- 避免生产环境测试：高并发请求可能影响线上服务，严重时甚至导致死机。
- 注意 Keep-Alive：启用 HTTP Keep-Alive（-k 参数）可减少 TCP 连接开销，但需确认服务器支持。
- 超时设置：使用 -t 参数可限制测试时长，与 -n 互斥，防止测试无限进行。
- User Agent 影响：ab 所使用的 User Agent 字串可能没有被网站纪录分析软件正确分类，执行 ab 可能会影响到原本分析流量纪录的报表。
参考来源
- Apache HTTP Server Project Documentation (Official)
- Linux 系统性能监控工具手册 (top, vmstat, iostat)