理论上 QA 需要在测试用例中覆盖性能验证 ，露馅但现实情况往往是压测：一旦线上出问题，开发、利器测试、速上手服运维一个都跑不了 。露馅

所以，压测作为开发同学 ，利器给自己的速上手服开发机装个压测工具并不多余。除了大家熟悉的露馅 JMeter
，本篇要介绍一款小巧高效的压测命令行工具 —— Apache Bench（简称 ab） 。它没有复杂的利器 GUI，却能精准揭示服务器在压力下的免费模板速上手服表现
，轻量、露馅直接、压测开箱即用
，利器是开发者压测的“入门必修课”。

Apache Bench 是什么

Apache Bench（ab）是 Apache HTTP Server 项目自带的一个压力测试工具 ，主要用于评估 Web 服务器在不同负载下的响应能力。它的优势在于：

命令行即开即用：一条命令就能让服务器“压力山大”。全方位指标输出：响应时间、建站模板吞吐量、失败请求数、分布统计等，一目了然。轻量便携：无需复杂配置 ，也不用安装额外依赖。

换句话说，运维要做容量规划，测试要找瓶颈，开发要验证优化效果，ab 都是随手能掏出来的“小钢炮”。

安装方式

安装 ab 的方式因系统不同而异，常见操作系统的高防服务器安装方式如下 ：

Linux (Debian/Ubuntu)sudo apt-get install apache2-utilsLinux (CentOS/RHEL)sudo yum install httpd-tools # 或者 dnfmacOS 一般系统自带，直接执行 ： ab -V

如果提示未找到
，可以用 Homebrew：

brew install apache2-utils1. Windows 建议在 WSL 环境下运行，或者在 Apache HTTP Server 的 /bin 目录下找到 ab.exe 。

安装完成后 ，在任何目录下执行 ab -V 能看到版本号
 ，就说明准备就绪了 。

入门示例：压测 GET 接口

假设我们在本地 Spring Boot 项目 /project/demo 下写了一个简单接口
：

package com.icoderoad.demo.controller; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RestController; @RestController public class DemoController { @GetMapping("/demo") public String demo() { return "this is a demo"; } }

启动项目后，我们用 ab 执行压测：

复制ab-n1000-c100 http://localhost:8080/demo1. -n 1000 ：一共发起 1000 个请求。-c 100：模拟 100 个并发用户。http://localhost:8080/demo ：目标地址
。

运行后，ab 会输出一份完整报告
，包括请求成功数 、失败数、香港云服务器QPS（每秒请求数）、响应耗时、分位数分布等 。比如 Requests per second: 120.50 [#/sec] 就直观地告诉你 ：服务器每秒能处理多少请求 。

进阶用法：POST 与更多参数

仅靠 GET 请求显然不够 ，ab 同样支持 POST 压测 。假设我们有一个接口 ：

复制@PostMapping("/sum") public Response<Integer> sum(@RequestBody List<Integer> list) { return new Response<>(list.stream().mapToInt(Integer::intValue).sum()); }

我们准备一个 req.json 文件：

执行命令：

ab -n 10 -c 2 -p req.json -T application/json http://localhost:8080/sum

常用参数说明：

-p file：指定 POST 请求体文件。-T ：设置 Content-Type，例如 application/json。-C：添加 Cookie 模拟用户登录。-H：自定义 Header，例如鉴权头
。-k：启用 Keep-Alive
 ，减少连接开销 ，提高压测真实性 。

通过灵活组合参数，亿华云ab 能满足大部分日常压测场景。

为什么要压测

压测的意义在于数据驱动 ，而不是“感觉”
。

性能摸底  ：服务器能抗多少并发？单个请求平均响应时间是多少 ？发现瓶颈：是 CPU 顶不住，还是数据库拖后腿？验证优化  ：改完代码后，性能是真提升了，还是心理作用 ？资源规划：促销活动预计有多少用户涌入？需要扩多少台机器 ？

一句话 ：压测是发现性能问题的显微镜，源码下载也是验证优化效果的试金石。

实战与注意事项

不要随便压生产：ab 发起的流量可能直接拖垮线上服务，务必在测试环境进行。循序渐进
：从 -c 1 开始，逐步加压 ，不要一上来就是“百万并发” 。关注失败请求 ：Failed requests 一定要看清原因 ，是超时还是 5xx。多次对比：单次压测结果可能受网络波动影响 ，多次取平均更可靠 。适用范围有限：ab 适合高频、简单请求 ，不适合复杂业务链路（如登录、跳转、多步骤交互），这时需要 JMeter 、Locust 或 k6  。

结论

压测是保障系统稳定性的最后一道关口 
，而 Apache Bench 就像一把“小刀” ，虽然简洁，却能切中要害 。

它没有 JMeter 那么重型，但足够高效、易上手。对于开发者而言 ，熟练掌握 ab 能在开发阶段就提前发现并规避潜在问题 ，把性能隐患扼杀在萌芽阶段 。

所以，下次上线前，不妨在 /opt/java/tools/ab 下敲几条命令 ，看看你的服务能不能扛住真实流量的冲击。

毕竟 ，没有经过压测的服务 ，就像未经考验的桥梁，随时可能在负荷面前“露馅”。

(责任编辑：数据库)