吞吐测试概述

吞吐测试，说白了就是看你的系统到底能扛多少活。

我刚开始做性能测试那会儿，总觉得这玩意儿挺玄乎。后来踩的坑多了，才明白——吞吐测试是所有性能测试的基石。你连系统能处理多少请求都不知道，后面的优化、扩容、限流全都是拍脑袋。

这一章，咱们先把概念理清楚。

什么是吞吐测试

吞吐测试，就是给系统施加持续的压力，测量它在单位时间内能处理多少请求。

你可以把它想象成一条高速公路的收费站。吞吐测试要回答的问题就是：这个收费站，一分钟能放过去多少辆车？

注意，这里的关键词是「持续」。不是瞬间爆发，而是稳定地、持续地处理。我见过不少团队，拿个压测工具随便跑几秒，看到 QPS 挺高就以为系统没问题。结果上线第一天，用户量一上来，系统直接挂了。

嗯，这里要注意：吞吐测试测的是稳态能力，不是峰值能力。

吞吐测试的核心指标：TPS 与 QPS

这两个概念，是吞吐测试里最基础、也最容易搞混的。我面试过不少人，能把它们说清楚的，真不多。

指标	全称	含义	典型场景
TPS	Transactions Per Second	每秒完成的事务数	数据库、支付、订单系统
QPS	Queries Per Second	每秒完成的查询数	搜索引擎、API 网关、读接口

TPS 强调的是「事务」。一个事务可能包含多个操作。比如你在电商网站下单，从点击「提交订单」到收到「下单成功」的响应，这整个流程算一个事务。它可能包含了：校验库存、扣减余额、生成订单、发送消息……这一串动作。

QPS 强调的是「查询」。它通常指一次请求-响应的过程。比如你查一个商品详情，发一个 GET 请求，拿到 JSON 数据，这就是一次查询。

我个人习惯这样区分：

• 如果系统是写多读少，或者操作有事务边界（比如支付、下单），我优先看 TPS。
• 如果系统是读多写少，或者只是简单的查询接口，我优先看 QPS。

但说实话，很多场景下这两个指标是混着用的。你打开一些压测工具的报告，它可能把 QPS 和 TPS 都叫「吞吐量」。别纠结名字，关键是理解它背后衡量的是什么。

吞吐测试与并发测试的区别

这个问题，我几乎每次培训都会被问到。很多人觉得「并发高就是吞吐高」，其实不是。

咱们用个例子说明白。

假设你开了一家奶茶店：

• 并发测试：看的是店里同时能站多少人。你让 100 个人同时挤进店里，看会不会把门挤坏、柜台会不会塌。
• 吞吐测试：看的是店员一小时能做多少杯奶茶。你让 10 个人排队，看店员能不能稳定地一小时做出 30 杯。

你看，这两个维度完全不同。

维度	吞吐测试	并发测试
关注点	单位时间内的处理量	系统同时承载的连接数
核心指标	TPS / QPS	并发用户数 / 并发连接数
测试方式	持续加压，观察稳态	瞬间施压，观察极限
典型问题	处理能力不足、资源耗尽	死锁、连接池溢出、线程阻塞

我曾经遇到过一个项目，开发说系统能支持 5000 并发。我一测，确实能连上 5000 个连接，但 TPS 只有 200。说白了，5000 个人挤进去了，但没人干活。这就是典型的「并发高、吞吐低」。

反过来，也有系统并发不高，但吞吐很稳。比如一些老牌中间件，并发连接数限制得很死，但每个连接的处理效率极高。

知识体系总览

这一章的内容，我用一张图帮你串起来。

这张图把本章的三个核心知识点串在了一起。你从「吞吐测试」出发，左边是定义，中间是指标，右边是区别。每个分支下面还有更细的子节点。

我个人建议你把这图存下来。后面讲到环境搭建、脚本编写、结果分析的时候，你会反复回到这张图上来。