ApacheBench终端API压力测试方法与实战指南

你已经上线了一个 API 接口。它在 Postman 里能够正常返回正确的 JSON，但当 200 个客户端同时请求这个接口时，实际表现会怎样，你可能并不清楚。它到底能扛住每秒 500 次请求，还是并发一到 50，响应延迟就明显飙升甚至失稳？使用 ApacheBench，只需一条命令，就能快速得到答案。

ApacheBench（命令为 ab）是一款经典的命令行压力测试工具，用于向单个 URL 发送固定数量的 HTTP 请求，并输出吞吐量、延迟等性能指标。它随 Apache HTTP Server 一同提供，已经使用了很多年。由于体积轻、启动快、上手门槛低，它非常适合用来快速评估单个 API 接口能够承受的负载能力。

本指南将带你了解如何安装 ab、执行基础压力测试、压测 POST 接口、正确解读测试结果，以及在哪些场景下 ab 不再是最佳选择。文中提到的每个命令，都对应官方 Apache ab reference 中记录的参数。

什么是 ApacheBench 以及它从何而来

ab 是 Apache HTTP Server 自带的基准测试客户端，名称即 ApacheBench 的缩写。它会针对单个 URL 建立连接，并在你设置的并发范围内尽可能快速地发送请求，记录每一次响应耗时，最后输出一份性能分析摘要。

如果你想先复习如何手动构造 JSON 请求 body，可以参考如何使用 curl 发送 POST JSON 数据。相同的 body 内容也可以直接作为 ab 的 payload 文件来使用。

读取输出结果

执行完成后，终端会输出一大段结果信息。下面是一个裁剪后的示例：

Concurrency Level: 50 Time taken for tests: 4.212 seconds Complete requests: 1000 Failed requests: 0 Non-2xx responses: 0 Requests per second: 237.42 #/sec Time per request: 210.598 ms Time per request: 4.212 [ms] (mean, across all concurrent requests) Transfer rate: 142.31 [Kbytes/sec] receivedConnection Times (ms) min mean[+/-sd] median max Connect: 5 18 9.4 16 64 Processing: 22 189 41.2 182 310 Waiting: 21 177 39.8 171 295 Total: 31 207 42.7 201 338Percentage of the requests served within a certain time (ms) 50% 201 66% 221 75% 236 90% 268 95% 291 99% 324 100% 338 (longest request)

首先建议重点查看以下几个字段：

• Requests per second（每秒请求数）代表吞吐量，是请求总数除以测试总耗时得出的指标。通常来说，这个值越高越好。
• Failed requests（失败请求数）和 Non-2xx responses（非 2xx 响应数）可以帮助你判断服务端是否真的顶住了压力，还是已经开始报错。如果一半响应都返回 500，那么即使每秒请求数看起来很高，也没有实际意义。所以在相信吞吐量之前，一定先检查这两项。
• Time per request（每个请求耗时）会出现两次。第一行表示单个用户实际感知到的平均等待时间（并发数乘以总时间再除以请求数）。第二行注明为“across all concurrent requests”，表示并发条件下请求完成之间的平均间隔。对最终用户来说，第一项更值得关注。

Percentage of the requests served within a certain time（在特定时间内完成的请求百分比）这一部分通常最有参考价值。它按照百分位进行统计。50% 行就是中位数，95% 和 99% 行则反映了长尾延迟。在上面的示例中，一半请求在 201ms 内完成，但仍有 1% 的请求耗时达到 324ms 或更久。真正影响用户体验的，往往不是平均值，而是这些尾部慢请求，因此在 API 性能测试中，应重点关注第 95 和第 99 百分位。

如果你想导出可用于图表分析的原始数据，可以添加 -e results.csv，生成包含“百分位数-耗时”对应关系的 CSV 文件；或者添加 -g results.tsv，输出适合 gnuplot 使用的数据文件。

什么时候 ab 不再是合适的工具

ab 的定位本来就非常聚焦，因此也必须清楚它的边界和局限，避免在不适合的场景中误用。

每次运行只能测试一个 URL。ab 只适合对单个 API 接口做压力测试，无法编写串联业务流程的脚本，例如先登录鉴权、再创建资源、最后查询资源。真实用户路径通常会依次访问多个接口，而这一类多步骤流程并不是 ab 能处理的。

没有正确性校验能力。ab 只统计状态码和响应字节数，不会解析 JSON，也不会断言某个字段是否符合预期。也就是说，某个响应即使结构已经错误，只要状态码和长度满足条件，仍可能被视为成功。因此，性能压测结果并不能替代功能测试或接口测试。

HTTP 处理能力相对老旧。官方文档明确指出，ab 并未完整实现 HTTP/1.x，并且只接受某些特定格式的响应。同时它也不支持 HTTP/2。如果你的服务端在 HTTP/2 场景下性能表现不同，那么 ab 无法真实反映这部分差异。

单机发压能力有限。ab 运行在单台机器和单个进程中，当并发量提升到一定程度后，你测到的可能已经是本地压测客户端的瓶颈，而不是服务端本身的极限。官方文档甚至提醒过，ab 自身的解析开销有时也会影响性能分析结果。

这些限制并不意味着 ab 不好用。恰恰相反，它的用途一直都很明确：快速评估单个接口的吞吐量与基础响应能力。如果你的需求进一步升级，例如需要脚本化流程、分布式压测、复杂场景编排，或者支持 HTTP/2，那么就不应该强行让 ab 承担这些工作，而应改用更专业的 API 压力测试工具。比如 JMeter，就适合多步骤场景和分布式测试；此外，市场上也有不少覆盖更全面的负载测试方案可供选择。

功能测试的适用场景

吞吐量衡量的是性能维度，而正确性衡量的是结果维度，ab 并不负责后者。在正式对 API 接口进行压力测试之前，你应先确认接口在正常条件下能够稳定返回正确、完整且符合预期格式的数据。这类工作属于功能测试、接口测试和契约测试的范畴。

也正因为如此，除了 ab 之外，很多团队还需要一个完整的 API 管理与测试平台。Apifox 支持通过可视化断言来搭建测试场景，将多个请求串联为多步骤工作流，并根据数据模型校验响应内容，这些能力都是 ab 在设计上不具备的。你只需要保存一次这些测试场景，之后就可以在不同环境中重复执行。

对于持续集成场景，Apifox CLI 可以通过无头（headless）模式执行你已保存的测试场景。使用 Node 安装它：

npm install -g apifox-cli

接着可以针对指定环境运行已保存的测试场景或测试套件，并输出适合 CI 系统归档的报告：

apifox run --access-token "$APIFOXACCESSTOKEN" -t -e -r cli,html,junit

-t 参数用于通过 ID 指定已保存的测试场景、目录或套件；-e 参数用于选择运行环境；-r 参数用于从 cli、html、json 和 junit 中选择一个或多个报告生成器。如果需要进行数据驱动执行，可以再添加 -d（或 --iteration-data）并指定数据文件路径或测试数据 ID。这个 CLI 是无头运行模式，专门用于执行已保存的测试场景，因此几乎适用于所有支持 Node 的 CI 流程。它不是请求发送器，也不是负载生成器，而是专注于运行 ab 无法完成的功能测试。

一个健康、完整的 API 质量体系，通常需要将这两类工具结合使用。使用 Apifox 测试场景验证接口正确性，使用 ab 验证接口是否足够快、是否能承受目标负载。关于正确性验证，可以进一步参考 Apifox 性能测试指南和通用的 API 性能测试教程。

FAQ

ApacheBench 只能用于 Apache 服务器吗？

不是。虽然它叫 ApacheBench，但 ab 实际上可以向任何支持 HTTP 或 HTTPS 的服务端发送普通请求。无论你的服务运行在 Nginx、Node.js、Go、Python，还是其他 Web 服务环境中，都可以使用它。它与 Apache 的关系，仅仅是这个工具由 Apache HTTP Server 一同发布。

我应该使用多少并发量和请求数？

建议从较低并发开始逐步增加。你可以先尝试 -n 1000 -c 10，然后把 -c 依次提高到 25、50、100，观察每秒请求数什么时候开始停止增长，以及什么时候开始出现失败请求。这个拐点通常就意味着接口接近饱和。实际压测时，峰值并发量应尽量贴近真实业务流量，而不是随意选择一个看起来很大的数字。

为什么当 API 运行正常时，我的失败请求数却很高？

如果不同请求返回的响应长度不一致（对于动态 JSON 响应来说很常见），ab 会把这些请求标记为失败。此时可以添加 -l 参数，停止将长度差异计入失败请求。随后再查看 Non-2xx responses 这一行，确认底层是否真的存在服务错误。

ab 可以测试需要登录 Token 的接口吗？

可以，只要你已经拿到了 Token。使用方式很简单，通过 -H "Authorization: Bearer YOUR_TOKEN" 添加请求头即可。不过有一点同样重要：ab 无法先执行登录、动态获取新的 Token，再继续完成后续请求。换句话说，它不支持多步骤认证工作流。遇到这种需要场景编排的 API 测试需求，更适合使用 Apifox 这类支持流程化测试的工具。

ab 支持 HTTP/2 吗？

不支持。ab 使用的是 HTTP/1.x，而且根据官方说明，它甚至没有完整实现这一协议。如果你的服务在 HTTP/2 下的性能表现非常关键，那么应改用支持 HTTP/2 的专业压测工具。

开发必备：API 全流程管理神器 Apifox

在介绍完上面的 ApacheBench 用法与 API 压测思路后，我还想额外推荐一个对开发者同样很有价值的效率工具——Apifox。作为一款集 API 文档、调试、设计、测试、Mock、自动化测试于一体的平台，Apifox 已成为许多团队提升研发效率和规范接口协作的重要选择。

如果你正在开发项目，不妨体验一下它简洁友好的界面设计。它全面兼容 Postman 和 Swagger 数据格式，导入接口数据非常方便，即使是刚接触 API 管理的新手，也能快速上手，点击这里即可注册使用。

值得一提的是，除了个人开发者和常规团队协作场景外，对于有更高安全合规要求、或者需要在内网环境中部署协作平台的企业，Apifox 还提供了深度定制的私有化部署方案。