电脑工具压力测试如何简易测试接口并发承载能力

本文目录导读：

1. 方法一：使用 curl（仅做基本测试）
2. 方法二：使用专门的轻量级压测工具（推荐）
3. 简易判据（对于大多数内部工具或小应用）
4. 方法三：浏览器开发者工具（最简易的“伪并发”）
5. 重要提示：不要在你的生产环境直接做！
6. 总结操作步骤（2 分钟完成）

对接口进行简易的并发承载能力测试，不需要很复杂的商业软件，以下提供两种最常见、操作最简单的方法：使用命令行工具（适合极速验证）和使用压测脚本（适合稍微正式一点的测试）。

使用 curl（仅做基本测试）

如果你只有几分钟，且需要看接口能不能被多个请求同时打，curl 配合 bash 的 seq 或循环可以快速验证。

# 并发发送 10 个请求，测试 GET 接口
seq 1 10 | xargs -P 10 -I {} curl -s -o /dev/null -w "Request {}: HTTP %{http_code}\n" "https://your-api.com/test"

• 原理：-P 10 表示同时跑 10 个进程，每个进程发起一个 curl 请求。
• 查看结果：如果输出里出现大量 HTTP 000（连接失败）、HTTP 500（服务端错误）或响应时间极长（未显示具体时间，但你可以加 -w 里的 %{time_total} 查看）,说明并发能力不足。

使用专门的轻量级压测工具（推荐）

这是最通用且足够“简易”的方法，推荐 hey 或 wrk，它们安装简单（即使是 Windows 也有对应包），能直接输出QPS（每秒请求数）和延迟分布。

安装（选一个即可）

• Mac：brew install hey 或 brew install wrk
• Linux：下载二进制文件或 apt install hey / apt install wrk
• Windows：scoop install hey 或用 WSL（Windows Subsystem for Linux）。

执行并发测试

以 hey 为例，语法是 hey -n [总请求数] -c [并发数] [URL]

# 测试：模拟 50 个用户同时并发，总共发送 500 个请求
hey -n 500 -c 50 "https://your-api.com/login?user=test"
# 测试 POST 接口（带 JSON 数据）
hey -n 500 -c 50 -m POST \
  -H "Content-Type: application/json" \
  -d '{"username":"test","password":"123"}' \
  "https://your-api.com/login"

如何看结果（简易判断标准）

执行后，命令会输出类似下面的数据，你只需要关注红色标记的 3 行：

Summary:
  Total:        2.3456 secs     # 总耗时
  Slowest:      1.2345 secs     # 最慢请求的延迟
  Fastest:      0.0012 secs
  Average:      0.2345 secs     # 平均延迟
  Requests/sec: 213.15          # <--- 核心指标：QPS（每秒查询数），越高越好
Status code distribution:
  [200] 500 responses           # <--- 核心指标：所有响应都是 200（无 4xx/5xx 错误）
Latency distribution:
  10% in 0.0500 secs
  50% in 0.2000 secs            # 50% 的请求在 0.2 秒内完成（P50）
  90% in 0.4500 secs            # 90% 的请求在 0.45 秒内完成（P90）
  99% in 0.9000 secs            # <--- 核心指标：99% 的请求在 0.9 秒内完成（P99），若此处数值很高说明有慢请求

简易判据（对于大多数内部工具或小应用）

• 合格：QPS > 200，且所有请求返回 200，P99 延迟 < 1秒。
• 较差：出现 5xx 错误（服务器扛不住）、4xx（限流）、连接超时。
• 需优化：P99 延迟超过 3秒 或 QPS 低于 50。

浏览器开发者工具（最简易的“伪并发”）

如果连命令行都不想用,可以：

1. 在浏览器（Chrome/Edge）里打开 F12 > Network
2. 找到你的接口，右键选择 “Replay XHR”（重放）多次（比如连点 10 下）。
3. 观察下方 瀑布图（Waterfall）：
   • 如果所有请求几乎是同时开始、同时结束，说明接口处理很快,无排队。
   • 如果后面的请求等待时间极长（瀑布图变成阶梯状），说明并发线程池满了,请求在排队。