一、接口压力测试概述

1.1 压力测试到底在测什么？

先聊聊压力测试的目标。我个人习惯把这个问题拆成三个层面：

• 能不能扛得住 —— 系统在预期负载下，响应是否正常
• 什么时候会崩 —— 负载超过预期时，系统的拐点在哪里
• 崩了以后能不能回来 —— 系统恢复能力怎么样，会不会雪崩

说白了，压力测试就是为了找到系统的「天花板」。我在项目中遇到过好几次，线上流量一涨，数据库连接池先打满，然后整个服务全挂。嗯，这都是压测没做到位的后果。

1.2 三种压测类型，你分得清吗？

我见过不少团队把这三类混着用。其实它们的侧重点完全不同——

负载测试是在问「达标了没」。比如你承诺 1000 QPS，那就压到 1000 QPS，看看各项指标是否满足 SLA。

压力测试是在问「极限在哪」。我曾经把一个接口从 100 QPS 一直往上顶，到 800 QPS 时 CPU 突然飙到 95%，响应时间从 50ms 跳到 2s——这个拐点就是我们要找的数据。

稳定性测试最容易被人忽略。你想想看，跑 10 分钟和跑 10 小时，内存增长曲线完全不一样。我记得有个项目，压测 1 小时一切正常，跑到第 6 小时时，Old Gen 直接撑爆，Full GC 把服务拖死。

1.3 压测和性能测试，不是一回事

很多人把这两个概念混着用，但在我看来，它们的出发点完全不同——

打个比方：性能测试就像你测一辆车的百公里加速，压力测试则是看这辆车满载爬坡时，发动机什么时候过热、轮胎什么时候打滑。

1.4 行业里常用的工具

这些年我用过不少工具，简单说说我的主观感受——

• JMeter：入门最友好，图形界面点一点就能跑。但脚本一复杂，XML 配置文件你会想哭。
• Locust：用 Python 写脚本，这点很加分。我偏好用它做协议简单的 HTTP 压测。
• wrk / wrk2：轻量级利器，一个命令就能压出漂亮的数据。缺点是不能做复杂业务流程。
• Gatling：Scala 写脚本，性能非常好。团队里有人懂 Scala 的话，首选。
• k6：近几年很火的工具，JavaScript 写脚本，grafana 生态集成得很好。

1.5 本章知识体系

下面这张图可以帮你把第一章的内容串起来——

1.6 几个避坑提醒

做压测这么多年，踩过的坑不少。列几个我觉得最有必要说的——

• 不要只压单机：我曾经在项目中只压了单台机器，结果上线后流量被负载均衡分散到四台机器上，压测数据完全失真。
• 注意压测客户端本身的瓶颈：有一次我压接口，CPU 先打满的竟然是发压机器本身，而不是目标服务。
• 监控一定要跟上：光有 QPS 和响应时间不够，CPU、内存、IO、GC、数据库连接池——少了任何一块你都有可能漏掉关键线索。
• 小心「冷启动」效应：JIT 编译、缓存预热、连接池初始化都会让前几秒的数据偏低。我一般会先跑 30 秒热身，再正式采集数据。