深色模式
性能压测入门
压测的目的不是"打挂它"，而是找到「延迟开始明显上升」的那个拐点 QPS。本文用 wrk（推荐）和 ab（应急）完成一次标准基线压测。
适用环境
- Linux 压测机一台，与被测机网络延迟 < 2ms（同机房/同 VPC）
- 被测服务已部署，健康检查通过
- 压测机 CPU 核数 ≥ 被测机
bash
# 检查压测机资源，压测机本身不能成为瓶颈
nproc; free -g | head -2; ulimit -n1
2
2
操作步骤
1. 安装工具
bash
# wrk（源码编译，需要 gcc 与 make）
git clone --depth=1 https://github.com/wg/wrk.git && cd wrk && make -j"$(nproc)"
sudo cp wrk /usr/local/bin/
# ab（apache2-utils / httpd-tools）
sudo apt-get install -y apache2-utils # Debian/Ubuntu
sudo yum install -y httpd-tools # RHEL/CentOS1
2
3
4
5
6
7
2
3
4
5
6
7
2. 提高压测机的连接与端口限制
bash
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
ulimit -n 655351
2
3
2
3
3. 先做冒烟，确认接口正常
bash
curl -s -o /dev/null -w 'code=%{http_code} time=%{time_total}s\n' http://10.0.0.11:8080/api/order1
4. 用 wrk 做基线压测
bash
# -t 线程数(≈核数) -c 并发连接 -d 时长 --latency 输出延迟分布
wrk -t4 -c100 -d60s --latency http://10.0.0.11:8080/api/order1
2
2
重点看三行：Requests/sec（吞吐）、99%（P99 延迟）、Socket errors（异常）。
5. 阶梯加压找拐点
bash
for c in 50 100 200 400 800; do
echo "--- concurrency=$c ---"
wrk -t4 -c"$c" -d30s --latency http://10.0.0.11:8080/api/order \
| grep -E 'Requests/sec|99%'
done1
2
3
4
5
2
3
4
5
把结果画成表：并发上升、QPS 不再线性增长而延迟快速抬升的那个点，就是单机上限。
6. 用 ab 做快速验证（无 wrk 时）
bash
# -n 总请求数 -c 并发；-k 开启 keepalive
ab -n 20000 -c 200 -k http://10.0.0.11:8080/api/order1
2
2
ab 只看 Requests per second 和 99% 行即可，它只有单线程，并发高于 500 时压测机自身会先成为瓶颈。
验证
bash
# 同时观察服务端资源，确认瓶颈在 CPU 还是别处
ssh 10.0.0.11 'top -bn1 | head -12'
ssh 10.0.0.11 'iostat -x 1 3 | tail -n +4'1
2
3
2
3
合格的压测报告应包含：并发数、QPS、P50/P99、错误率、服务端 CPU/内存/IO 五项。
常见坑
直接在生产上压测
未做隔离的压测会打挂真实用户流量。必须在灰度环境或独立的压测集群做；确需在生产做全链路压测时，要提前做流量染色与降级开关，并选业务低峰期。
压测机与被测机混部
压测机 CPU 打满会让结果偏低，表现为"加压 QPS 不涨"。务必用独立机器，并在压测期间用 top 确认压测机 CPU < 80%。
只压 10 秒
Java/Go 服务有 JIT 与缓存预热过程，前 30 秒数据不可用。单次压测时长至少 60 秒，且先跑一轮预热再开始记录。
忽略错误率
QPS 很高但错误率 5%，说明已经过载。判定上限时必须同时满足：错误率 < 0.1% 且 P99 达标。