性能测试与基准：压测工具选型与基准制定

性能测试这件事，说白了就是给系统做一次「压力体检」。我在过去几年里踩过不少坑，最惨的一次是上线前压测数据看着挺漂亮，结果双十一流量一来，服务直接雪崩。嗯，从那以后我养成了一个习惯——压测不是走流程，而是真正摸清系统的底牌。

这一章我们聊聊三件事：压测工具怎么选、性能基准怎么定、报告怎么看。都是实战中反复用到的经验。

压测工具选型：wrk、JMeter、Locust

市面上的压测工具少说几十种，但真正在生产级场景里站稳脚跟的，也就那么几个。我个人习惯根据场景来选，而不是一把梭哈。

工具	核心特点	适用场景	学习成本
wrk	基于 C 语言，单机可压出数十万 QPS	快速摸底、接口级压测	低
JMeter	GUI 操作，插件生态丰富	复杂业务流程、分布式压测	中
Locust	Python 脚本，协程模式	自定义行为、持续集成	中高

wrk：轻量级利器

wrk 是我最常用的工具，没有之一。它用 C 语言写底层，利用操作系统的事件驱动机制，单机就能压出很高的并发。你想想看，一个命令行工具，几行参数就能跑起来，多省事。

# 一个典型的 wrk 压测命令
wrk -t12 -c400 -d30s http://target-service/api/v1/query

# 参数说明：
# -t12    : 12 个线程
# -c400   : 400 个并发连接
# -d30s   : 持续 30 秒

我在项目中遇到过一个问题：wrk 默认只支持 HTTP/1.1，如果你的服务用了 HTTP/2 或者 gRPC，那就得换方案了。另外，wrk 的脚本能力很弱，复杂的业务逻辑基本写不了。

JMeter：重型武器

JMeter 是 Apache 家的老牌工具，功能确实全面。GUI 界面拖拖拽拽就能配出一个复杂的压测场景，比如登录→查询→下单→支付这种多步骤流程。

但说实话，JMeter 的资源消耗比较大。我曾经用 JMeter 压一个高并发服务，结果压测机自己先撑不住了——CPU 飙到 95%，网络连接数爆表。后来我学乖了，分布式部署 JMeter，用一台 Master 控制多台 Slave 来分担压力。

# JMeter 分布式压测启动命令（Master 端）
jmeter -n -t test-plan.jmx -R slave1:1099,slave2:1099 -l results.jtl

Locust：灵活至上

Locust 用 Python 写脚本，自由度很高。你可以定义用户行为、控制请求间隔、甚至模拟真实用户的思考时间。它的 Web 界面能实时看到压测数据，这点比 wrk 友好。

# Locust 脚本示例
from locust import HttpUser, task, between

class WebsiteUser(HttpUser):
    wait_time = between(1, 3)  # 模拟用户思考时间

    @task(3)
    def query_user(self):
        self.client.get("/api/v1/user/123")

    @task(1)
    def create_order(self):
        self.client.post("/api/v1/order", json={"user_id": 123})

Locust 的协程模式让它能支撑大量虚拟用户，但 Python 的 GIL 限制了它的吞吐上限。我一般用它来做场景压测，而不是极限压测。

如何制定性能基准

性能基准不是拍脑袋定的，得有数据支撑。我见过不少团队，上来就说「目标 QPS 10 万」，结果连当前系统能扛多少都不知道。制定基准，我一般分三步走。

第一步：摸清当前水位

先跑一轮压测，拿到当前系统的极限值。注意，这里说的「极限」不是指系统崩溃的点，而是指响应时间还在可接受范围内的最大吞吐。

• 响应时间目标：比如 P99 < 200ms
• 错误率上限：比如 < 0.1%
• 资源利用率：比如 CPU < 80%，内存 < 70%

举个例子，我压一个订单服务，发现当 QPS 到 5000 时，P99 响应时间从 150ms 跳到了 350ms，错误率也到了 0.5%。那这个服务的当前水位就是 5000 QPS。

第二步：设定目标基准

目标基准要结合业务预期和资源成本。不能只看理想值，还得考虑线上流量的波动。

指标	当前值	目标值	备注
QPS	5000	8000	业务增长 60%
P99 响应时间	350ms	200ms	用户体验优化
错误率	0.5%	0.1%	稳定性要求
CPU 利用率	85%	70%	预留缓冲

第三步：建立基线版本

每次优化后，都要和基线版本对比。我习惯把基线数据固化到 CI/CD 流程里，每次代码合并前自动跑一轮压测，如果性能下降超过 5%，就阻断发布。

性能报告解读

压测跑完了，数据摆在那，怎么看？我见过有人盯着平均响应时间看半天，却忽略了 P99 和错误率。报告解读，我重点关注四个维度。

吞吐量与响应时间

吞吐量（QPS/TPS）和响应时间是一对冤家。系统在低负载时响应时间很漂亮，一旦压力上来，响应时间就会急剧上升。这个拐点就是系统的瓶颈点。

• 平均响应时间：参考价值有限，容易被长尾请求拉高
• P50/P90/P99：重点关注 P99，它代表最差的那 1% 用户的体验
• 最大响应时间：如果远高于 P99，说明有异常请求

错误率分析

错误率超过阈值，说明系统已经扛不住了。常见的错误类型有：

• 超时错误：连接池或线程池耗尽
• 5xx 错误：服务端内部异常
• 连接拒绝：端口或文件描述符耗尽

我曾经遇到过一个案例，压测时错误率突然飙升到 10%，查了半天发现是数据库连接池太小，请求全在排队等连接。调大连接池后，错误率直接降到 0.1%。

资源利用率

CPU、内存、网络、磁盘 I/O，这四个指标能帮你定位瓶颈在哪。

资源	高利用率可能的原因	优化方向
CPU	计算密集型、GC 频繁	算法优化、减少对象创建
内存	内存泄漏、缓存过大	堆外内存、限流缓存
网络	带宽不足、连接数过多	压缩、连接复用
磁盘 I/O	日志写入、数据库操作	异步写入、批量操作

性能报告模板

一份好的性能报告，应该让读者一眼看出问题在哪。我习惯用这个结构：

1. 测试概况：压测工具、环境、参数
2. 核心指标：QPS、P99、错误率、资源利用率
3. 趋势图：响应时间随并发变化的曲线
4. 瓶颈分析：定位到具体的模块或代码
5. 优化建议：可落地的改进方案

压测流程全景图

下面这张图概括了从工具选型到报告输出的完整流程，我每次做压测都按这个节奏走。

这张图把整个流程串起来了。从工具选型开始，到制定基准、执行压测、解读报告、优化迭代，最后回归验证，形成一个闭环。我每次做性能优化都按这个节奏走，很少跑偏。