一、压测认知篇：什么是吞吐压测、为什么需要压测、压测的核心指标

大家好，我是你们的老朋友。今天咱们聊聊吞吐压测。

说实话，我见过太多团队把压测当成「上线前的仪式」——跑一遍、截个图、汇报完就完事了。结果呢？线上流量一来，系统直接崩了。嗯，这种事我遇到过不止一次。

所以这一章，我想把压测最核心的认知讲清楚。说白了，就是三个问题：它是什么？为什么需要？怎么看结果？

1.1 什么是吞吐压测

吞吐压测，简单讲就是给系统灌流量，看它能扛多少。

你想想看，一个接口平时只有几十个请求，突然搞个秒杀活动，瞬间涌进来几万并发。系统扛不扛得住？这就是吞吐压测要回答的问题。

我个人习惯把压测分成两类：

• 容量压测：找系统的极限值，比如最大QPS是多少
• 稳定性压测：长时间跑，看会不会内存泄漏、GC频繁

吞吐压测更偏向第一类。它关注的是单位时间内系统能处理多少请求。

1.2 为什么需要压测

这个问题我问过不少新人。有人回答「为了性能优化」，有人回答「为了上线安心」。都对，但不够本质。

我自己的理解是：压测是为了消除不确定性。

举个例子。我之前负责过一个支付核心服务，代码review、单元测试都过了，上线前也跑了简单的压力测试。结果双十一当天，TPS冲到800的时候，数据库连接池直接打满了。为什么？因为压测时只测了单个接口，没考虑到多个接口共享连接池的情况。

你看，这就是不确定性。压测就是帮你把这些坑提前踩一遍。

具体来说，压测能帮你回答这几个问题：

• 系统能支撑多大的业务量？
• 瓶颈在哪里？是CPU、内存、IO还是网络？
• 扩容多少台机器才能满足目标？
• 代码改动后，性能是变好了还是变差了？

1.3 压测的核心指标

聊完概念，咱们看看具体怎么衡量。压测里最核心的四个指标，我一个个说。

1.3.1 QPS（每秒查询数）

QPS全称Queries Per Second，指的是系统每秒能处理的查询请求数量。

注意，这里的「查询」不一定是数据库查询。在压测语境下，它泛指所有请求。比如一个HTTP接口，每秒能响应1000次，那QPS就是1000。

我个人习惯用QPS来衡量读接口的性能。比如商品详情页、用户信息查询这些。

1.3.2 TPS（每秒事务数）

TPS全称Transactions Per Second，指的是系统每秒能完成的事务数量。

一个事务可能包含多个操作。比如下单这个动作，可能包括：创建订单、扣库存、生成支付单。这三个操作合在一起，才算一个完整的事务。

所以TPS更适合衡量写接口或复杂业务流程的性能。

1.3.3 RT（响应时间）

RT就是Response Time，从发出请求到收到响应的时间差。单位通常是毫秒。

这个指标很直观。用户点一下按钮，多久能看到结果？RT就是答案。

但要注意，RT不能只看平均值。我见过一个系统，平均RT是50ms，但P99（99%的请求）是2000ms。这意味着每100个用户里，就有1个要等2秒。这种体验其实很差。

所以我建议关注这几个分位值：

分位值	含义	参考标准
P50	一半请求的RT	通常<200ms
P90	90%请求的RT	通常<500ms
P99	99%请求的RT	通常<1000ms
P999	99.9%请求的RT	通常<2000ms

1.3.4 并发数

并发数指的是同一时刻系统正在处理的请求数量。

注意，并发数和QPS不是一回事。举个例子：

• 系统A：并发数100，每个请求处理10ms，QPS = 100 / 0.01 = 10000
• 系统B：并发数100，每个请求处理100ms，QPS = 100 / 0.1 = 1000

你看，同样的并发数，QPS可以差10倍。原因就在于RT不同。

它们之间的关系可以用一个公式表示：

QPS = 并发数 / RT（秒）

这个公式很重要。你想想看，如果RT从10ms涨到100ms，要保持QPS不变，并发数就得从100涨到1000。但并发数不是无限大的，它受限于线程池大小、数据库连接数、CPU核心数等资源。

所以压测时，我一般会同时观察这三个指标：

• 并发数是否达到预期
• RT是否在合理范围内
• QPS是否满足业务目标

任何一个指标异常，都说明系统有问题。

1.4 知识体系总览

说了这么多，咱们用一张图来总结一下本章的核心内容。

这张图把本章的核心内容串起来了。你记住三个关键词就行：是什么、为什么、怎么看。

下一章，我们会聊压测工具的选择和对比。到时候我会分享一些实际踩过的坑，比如JMeter和wrk到底该怎么选，什么场景用哪个更合适。

今天就到这里。记住，压测不是走过场，它是你系统上线的最后一道防线。