压力测试

• 测试系统能够运行的极限指标

参考指标

性能指标

指标	描述
每秒请求数（QPS）	系统每秒接收的 HTTP 请求数（如页面刷新、接口调用），常用于衡量接口层负载能力。 → 极限 QPS 下是否仍能正常响应，而非拒绝请求。
每秒事务数（TPS）	系统每秒能完成的 “完整业务事务”（如用户下单、支付）数量，是核心性能指标。 → 极限负载下 TPS 是否达到预期，是否出现 “TPS 骤降”（性能瓶颈信号）。
并发用户数	同时操作系统的用户数（如同时登录、下单的用户），反映系统对 “多用户并行操作” 的承载能力。 → 找到 “系统不崩溃的最大并发用户数”（如支持 10 万并发）。

响应指标

指标	描述
平均响应时间（ART）	所有请求从 “发起到接收响应” 的平均耗时（单位：毫秒 ms），直接影响用户体验。 → 极限负载下 ART 是否控制在合理范围（如核心接口≤500ms），是否大幅飙升。

稳定性指标

指标	描述
错误率	失败请求数占总请求数的比例（如接口返回 500 错误、超时）。 → 正常负载下错误率应≤0.1%，极限负载下若错误率骤升（如超过 5%），说明系统已接近崩溃。

资源指标

指标	描述
CPU 使用率	服务器 / 设备 CPU 的繁忙程度，正常负载应≤70%，极限负载若长期≥90%，会导致响应变慢。 → 需警惕 “CPU 飙升至 100% 且无法下降”（死循环 / 资源泄漏）。
内存使用率	系统占用的物理内存比例，若持续上升且不释放（内存泄漏），最终会导致 “内存溢出（OOM）” 崩溃。 → 极限负载下内存使用率应≤85%，且无持续增长趋势。
磁盘 IO 使用率	磁盘读写的繁忙程度（如数据库存储、日志写入），若 IO 使用率≥90%，会导致数据读写延迟。 → 需结合 “磁盘吞吐量（MB/s）” 判断是否达到硬件上限。
网络带宽使用率	系统收发数据占用的网络带宽比例（如直播推流、大文件传输）。 → 极限负载下带宽使用率若接近带宽上限（如 100M 带宽用满），会导致网络拥堵、丢包。

测试工具

wrk

• wrk 是一款现代 HTTP 基准测试工具，在单个多核 CPU 上运行时能够产生显著的负载。
• 官方文档：https://github.com/wg/wrk

安装

# mac 安装
brew install wrk

# 源码编译安装
git clone https://github.com/wg/wrk.git
cd wrk
make

参数说明

参数	描述
-t	线程数 推荐设置为 CPU 核心数的 1-2 倍
-c	每个线程保持的连接数 常规测试：100~500 然后逐步递增至500~5000,直到 QPS 不再增长或响应时间剧烈恶化 并发测试：1000~5000 然后逐步递增至10000+,直到 QPS 不再增长或响应时间剧烈恶化
-d	测试持续时间 快速验证：30s~1m 精准测试：3m~5m 稳定测试：30m~1h
--latency	显示响应时间的分布统计

测试案例

# 18 个线程，400 个连接，测试 30 秒，目标 URL
wrk -t18 -c400 -d30s --latency http://127.0.0.1:8100

结果分析

Running 30s test @ http://127.0.0.1:8100
  18 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     6.44ms   12.60ms 263.90ms   97.06%
    Req/Sec     2.61k     1.65k    5.38k    50.84%
  Latency Distribution
     50%    4.72ms
     75%    5.20ms
     90%    7.33ms
     99%   60.62ms
  1398928 requests in 30.05s, 759.12MB read
  Socket errors: connect 161, read 0, write 0, timeout 0
  Non-2xx or 3xx responses: 1398928
Requests/sec:  46560.98
Transfer/sec:     25.27MB

• 10 threads and 400 connections 表示运行 10 个线程，每个线程保持 400 个连接。

• Latency 表示响应时间的分布统计，单位为毫秒 ms。

• Req/Sec 表示每秒请求数（QPS），单位为次/秒。

• Avg 表示平均响应时间，单位为毫秒 ms。

• Stdev 表示响应时间的标准差，单位为毫秒 ms。

  • 反映了这些响应时间与平均值之间的偏离程度。
  • 标准差越靠近Avg，响应时间越集中，说明系统性能更稳定。
  • 标准差越远离Avg, 表示响应时间波动越大（有的请求很快，有的很慢），性能稳定性较差。

• Max 表示最大响应时间，单位为毫秒 ms。

• +/- Stdev 表示的是响应时间的标准差范围。

  • 此处显示97.06%，说明 97.06% 的请求响应时间在 6.44ms 加上或减去 12.60ms 的范围内，说明系统比较稳定。

• Latency Distribution 表示响应时间的分布统计，单位为毫秒 ms。

  • 50% 表示响应时间的中位数，即 50% 的请求响应时间小于等于 4.72ms。
  • 75% 表示响应时间的 75% 分位数，即 75% 的请求响应时间小于等于 5.20ms。
  • 90% 表示响应时间的 90% 分位数，即 90% 的请求响应时间小于等于 7.33ms。
  • 99% 表示响应时间的 99% 分位数，即 99% 的请求响应时间小于等于 60.62ms。

• 1398928 requests in 30.05s, 759.12MB read 表示在 30 秒内，共处理了 1398928 个请求，读取了 759.12MB 数据。

• Socket errors: connect 161, read 0, write 0, timeout 0 表示在测试过程中，有 161 个连接失败（连接超时），没有读取到数据，也没有写入数据。错误率：161 / 1493983 = 0.0107% < 0.1% ，说明系统在正常负载下，连接超时的错误率较低。

• Non-2xx or 3xx responses: 1398928 表示有 1398928 个请求返回了非 2xx 或 3xx 的状态码，说明有 1398928 个请求成功。成功率：1398928 / 1398928 = 100% 。

• Requests/sec: 46560.98 表示在 30 秒内，系统每秒处理了 46560.98 个请求也就是QPS=46560.98次/秒。

• Transfer/sec: 27.00MB 表示在 30 秒内，系统每秒传输了 25.27MB 数据。

K6

• Grafana k6 是一个开源、开发人员友好且可扩展的负载测试工具。
• 官方文档：https://grafana.com/docs/k6/latest/

安装

# mac 安装
brew install k6

# debian || ubuntu 安装
sudo gpg -k
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/k6-archive-keyring.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update
sudo apt-get install k6

测试案例

• 创建 test.js 文件

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
	vus: 100, // 虚拟用户数
	duration: '5s', // 测试时长
};

export default function () {
	const res = http.get('http://127.0.0.1:8100/api/login/env');
	console.log(res.status);
	check(res, { 'status was 200': (r) => r.status == 200 });
	sleep(1);
}

• 运行测试

k6 run test.js

ab 测试

安装

• 一般系统自带的，无需安装

参数说明

参数	选择	说明
-n	必选	总请求数，至少-c*10
-c	必选	并发数，相当于同时模拟多少个人访问url 配置服务日常并发量的 1/2~1 倍。 如日常 100 并发，设-c 50或-c 100
-t	可选	测试时长 设置-t时默认-n=50000,并且会忽略-n参数
-p	可选	POST 请求的请求体文件
-u	可选	PUT 请求的请求体文件
-k	可选 (推荐必选)	启用 HTTP 长连接 复用 TCP 连接（模拟浏览器 / 真实客户端的连接模式，更贴近实际场景）。
-r	可选 (推荐必选)	socket 错误时不中断压测 如连接超时、重置时继续执行（避免压测提前终止）。

测试案例

ab -n 50000 c 200 -k -r http://127.0.0.1:8100/api/login/env

结果分析

# ab版本说明
This is ApacheBench, Version 2.3 <$Revision: 1913912 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

# 请求次数说明
Benchmarking 127.0.0.1 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests

# 请求地址服务器说明
Server Software:
Server Hostname:        127.0.0.1
Server Port:            8100

# 请求地址路径说明
Document Path:          /api/login/env
Document Length:        19 bytes

# 发放级别 就是-c参数的值
Concurrency Level:      200
# 测试时长
Time taken for tests:   1.437 seconds
# 成功请求数
Complete requests:      50000
# 失败请求数
Failed requests:        0
# 非2xx响应数
Non-2xx responses:      50000
# 保持连接数
Keep-Alive requests:    50000
# 总传输字节数
Total transferred:      29650000 bytes
# 整个测试过程HTML页面实际的字节数
HTML transferred:       950000 bytes
# QPS请求每秒数
Requests per second:    34786.72 [#/sec] (mean)
# 平均响应时间
Time per request:       5.749 [ms] (mean)
# 每个请求的时间 0.029[毫秒]，意思为在所有的并发请求每个请求实际运行时间的平均值
# 由于对于并发请求 cpu 实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的
# 所以基本上第一个 Time per request 时间约等于第二个 Time per request 时间乘以并发请求数
Time per request:       0.029 [ms] (mean, across all concurrent requests)
# 传输速率，平均每秒的流量
Transfer rate:          20145.05 [Kbytes/sec] received

# 连接时间统计
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       5
Processing:     0    6   4.4      4      45
Waiting:        0    6   4.4      4      45
Total:          0    6   4.4      4      45

# 响应时间统计
Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      5
  80%      9
  90%     10
  95%     16
  98%     17
  99%     19
 100%     45 (longest request)