ab全称ApacheBench，是Apache HTTP Server项目提供的一个小型HTTP基准测试工具。在RHEL体系中，它被打包在httpd-tools软件包中，安装便捷、命令简单，常用来对Web服务做快速负载能力评估。测试时只需指定总请求数、并发数以及目标URL，就能得到吞吐量、响应时间和错误率等基础数据，非常适合在服务器上做第一轮性能冒烟测试。
一、安装与环境准备
在RHEL 8/9及兼容发行版上，ab并不是独立软件，而是由httpd-tools软件包提供。执行dnf install -y httpd-tools即可完成安装，老版本系统使用yum install -y httpd-tools。安装完成后运行ab -V可以查看版本，确认命令可用。
安装虽然简单，但直接跑高并发往往会被系统自身的文件描述符和端口范围卡住。默认的ulimit -n可能只有1024，当并发数超过这一数值时，ab会报Too many open files。测试前建议使用ulimit -n 65535临时调高限制，并通过sysctl net.ipv4.ip_local_port_range查看可用临时端口数量。如果端口范围过窄，连接建立速度也会受影响。
dnf install -y httpd-tools ab -V
ulimit -n 65535 sysctl net.ipv4.ip_local_port_range
如果测试目标是本机部署的Web服务，还需要留意防火墙和SELinux。RHEL默认启用firewalld和SELinux，对80、443等端口的访问策略可能影响ab的请求。可以使用firewall-cmd --add-service=http --permanent与setsebool -P httpd_can_network_connect on放开限制，或者临时将SELinux设为permissive进行诊断。不过生产环境下不建议直接关闭SELinux，只放开必要的布尔值即可。
二、常用参数与典型测试场景
ab的核心参数非常简洁：-n表示总请求数，-c表示同时发起的并发数。-t可以指定测试时长，例如ab -t 30 -c 50会持续压测30秒，不限制总请求数。-k启用HTTP Keep-Alive，让连接复用以减少TCP握手开销，适合模拟浏览器行为。-p配合-T可发送POST请求，-H用于添加自定义请求头。
最简单的GET基准测试可以这样写：
ab -n 2000 -c 200 http://192.168.1.10/
这条命令会向目标URL发起2000次请求，同时保持200个并发连接。测试完成后ab会输出请求总数、成功数、每秒请求数等指标。如果要模拟真实浏览器长连接，可以加上-k，同等并发下通常吞吐会提升。
POST接口测试则需要先把参数写入文本文件，然后通过-p指定。以登录接口为例：
printf "username=testuser&password=testpass\n" > postdata.txt ab -n 1000 -c 100 -p postdata.txt -T application/x-www-form-urlencoded http://192.168.1.10/login
这里必须注意，默认ab发送POST时会自动添加Content-Type: text/plain，如果服务端只接受表单编码或JSON，需要通过-T显式指定，否则会返回415或参数解析失败。若接口要求JSON，可以把请求体写成JSON字符串，并用-H "Content-Type: application/json"覆盖。
带认证与自定义头的场景也很常见。比如访问需要Bearer Token的API：
ab -n 500 -c 50 -k -H "Authorization: Bearer abcdef123456" -H "Accept: application/json" http://192.168.1.10/api/status
注意参数顺序没有强制要求，但URL必须放在最后。若使用-A参数可以发送HTTP Basic认证，-X可以指定代理服务器。对于HTTPS站点，ab默认不校验证书，适合内部测试，但SNI支持较弱，测试多域名时需要谨慎。
三、读懂测试输出中的关键指标
ab跑完后会打印一段完整报告，重点不是“测试完成”，而是几个容易误解的数值。先看一段典型输出：
Server Software: nginx/1.24.0
Server Hostname: 192.168.1.10
Server Port: 80
Document Path: /
Document Length: 6120 bytes
Concurrency Level: 100
Time taken for tests: 12.345 seconds
Complete requests: 2000
Failed requests: 0
Total transferred: 13204000 bytes
HTML transferred: 12240000 bytes
Requests per second: 162.01 [#/sec] (mean)
Time per request: 617.326 [ms] (mean)
Time per request: 6.173 [ms] (mean, across all concurrent requests)
Transfer rate: 1044.23 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 8 4.1 7 25
Processing: 52 602 132.6 598 1345
Waiting: 50 598 132.1 592 1339
Total: 58 610 133.9 605 1355
Percentage of the requests served within a certain time (ms)
50% 605
66% 648
75% 670
80% 685
90% 742
95% 839
98% 872
99% 912
100% 1355 (longest request)
首先看Failed requests，它必须为0或非常接近0，任何非零值都说明有连接失败、超时或响应长度不一致。接下来看Requests per second，它反映整体吞吐；但更值得看的是Time per request右侧的第二个值——6.173毫秒表示平均每个请求在并发情况下的实际服务时间，而617毫秒是并发等待后的平均响应时间，两者含义不同。
连接时间分布表中，Connect表示建立TCP连接耗时，Processing包含等待与处理时间，Waiting通常指服务端处理时间。如果Connect占比很高，可能网络链路有抖动；如果Processing远大于Waiting，可能是服务器排队或带宽限制。百分位数据能看出长尾延迟：上面99%请求在912毫秒内完成，但最大达到1355毫秒，说明存在明显长尾，需进一步定位。
结合RHEL系统工具可以验证瓶颈在哪里。测试期间打开另一个终端，用vmstat 1观察CPU和上下文切换，用top -H查看高负载线程，用ss -s统计当前连接状态。如果ab所在机器的CPU先跑满，说明压测端已到极限，应降低并发或换用多台机器。如果服务端CPU正常但响应变慢，则要检查数据库连接池、文件句柄等。
四、避开ab的局限与高频踩坑点
ab虽然方便，但它是一个单机、基于线程的压测工具，不能模拟分布式负载，也不能执行复杂的业务场景。并发数较高时，ab本身会消耗大量CPU和内存，导致压测结果偏低。实际基准测试中，如果Requests per second过高或Failed requests突然增加，首先要确认ab所在主机与被测目标之间的网络质量，最好同网段或本机回环测试。
另一个典型问题是高并发下的socket: Too many open files。这通常不是目标服务的问题，而是ab进程自身达到文件描述符上限。解决办法是执行ulimit -n 65535，或者降低并发数。还有连接状态中的TIME_WAIT堆积，如果目标服务端没有启用连接复用，大量短连接测试结束后会产生成片TIME_WAIT，影响后续连接建立。可以在服务端调优内核参数，例如sysctl -w net.ipv4.tcp_tw_reuse=1，但需要确认内核版本支持。
AB对动态页面的测试也存在误区。很多人在压测一个带缓存的接口时，第一次结果很好，第二次却骤降，原因可能是服务端缓存失效或者数据库锁竞争。为了对比一致，每次测试前应清理缓存或发送禁止缓存的请求头。例如静态文件可以直接用-H "Cache-Control: no-cache"，动态接口则要确认数据是否发生变化。此外，ab默认使用HTTP/1.0，除非加了-k才是HTTP/1.1，所以如果想模拟现代浏览器，务必开启Keep-Alive。
对于需要更真实并发模型或报告图形的场景，建议将ab作为快速冒烟工具，正式压测转向wrk、JMeter或Locust。ab的价值在于开箱即用、命令简单，适合在RHEL服务器上快速验证某个URL的基础吞吐能力，但不能替代完整的性能测试体系。