1. 吞吐压测概述：什么是吞吐压测、为什么需要吞吐压测、压测的核心指标

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

说实话，我见过太多团队，上线前拍着胸脯说“没问题”，结果一上线就被用户流量冲垮。为什么会这样？说白了，就是没做吞吐压测。你想想看，一辆车出厂前都要做碰撞测试，你的系统上线前，难道不该做一次“流量碰撞”吗？

1.1 什么是吞吐压测

吞吐压测，简单讲就是：模拟大量用户同时访问你的系统，看看它能扛住多大的压力。

我习惯把它比作“给系统做一次极限运动测试”。你平时跑5公里没问题，但让你跑个马拉松呢？系统也一样，日常几百人访问没问题，但突然来几万人呢？

吞吐压测关注的是系统在单位时间内能处理多少请求。它不像压力测试那样非要压到系统崩溃，而是找到那个“既能跑得快、又能跑得稳”的最佳状态。

1.2 为什么需要吞吐压测

我在项目中遇到过不少“血泪教训”。有一次，一个电商平台上线前没做压测，结果双十一当天，支付接口直接超时，用户疯狂投诉。后来复盘发现，数据库连接池配得太小了，平时够用，流量一上来就崩了。

吞吐压测能帮你解决三个核心问题：

• 容量规划：你的系统到底能扛多少并发？需要多少台机器？
• 瓶颈定位：是数据库慢了？还是网络带宽不够？还是代码本身有性能问题？
• 稳定性验证：系统在高负载下会不会出现内存泄漏、连接池耗尽等问题

嗯，这里要注意：吞吐压测不是一次性的工作。我建议每次大版本上线前，都要跑一轮。尤其是那些涉及核心链路的改动，比如支付、登录、下单这些。

1.3 压测的核心指标

吞吐压测离不开几个关键指标。我刚开始做压测时，也搞混过QPS和TPS，后来踩了坑才真正理解它们的区别。

1.3.1 QPS（每秒查询数）

QPS全称是Queries Per Second，也就是每秒能处理多少个查询请求。它通常用来衡量读接口的性能。

举个例子，你有一个商品详情页接口，每秒能响应5000次请求，那它的QPS就是5000。

1.3.2 TPS（每秒事务数）

TPS是Transactions Per Second，每秒能完成多少个完整的事务。一个事务可能包含多个操作，比如下单这个动作，可能包括：查询库存、扣减库存、生成订单、更新用户余额等。

我曾经犯过一个错误：把QPS当成了TPS来用。结果压测报告里写“系统TPS能达到10000”，实际上那是QPS，真正的TPS只有2000。嗯，这个坑大家千万别踩。

指标	含义	典型场景
QPS	每秒查询数	读接口、搜索接口
TPS	每秒事务数	下单、支付、注册

1.3.3 RT（响应时间）

RT就是Response Time，从发出请求到收到响应所花的时间。通常看平均值、P99、P95这几个分位值。

我个人习惯重点关注P99。为什么？因为平均值容易被“平均”掉。比如100个请求里，99个都是10ms，但有一个是10秒，平均值才100ms左右，看起来还行。但实际上那个10秒的请求已经让用户崩溃了。

1.3.4 并发数

并发数指的是同一时刻有多少个请求在处理。它和QPS、RT之间有一个经典公式：

并发数 = QPS × RT（秒）

举个例子，如果你的系统QPS是1000，平均RT是200ms，那并发数就是1000 × 0.2 = 200。也就是说，同一时刻有200个请求在处理。

这个公式非常实用。我经常用它来估算系统需要多少线程池、数据库连接池。比如你算出来并发数是500，那数据库连接池至少得配500以上，否则就会排队等待。

1.4 核心指标之间的关系

这四个指标不是孤立的，它们互相影响。我画了一张图，帮你理清它们的关系：

从图上你能看到：QPS和RT决定了并发数，而并发数反过来又会影响TPS。如果并发数太高，系统资源耗尽，RT就会飙升，QPS反而下降。这就是所谓的“拐点”。

我记得有一次压测一个支付系统，刚开始并发数从100涨到500，QPS也跟着涨。但到了600并发时，QPS突然掉头向下。后来发现是数据库连接池满了，请求开始排队等待。这就是典型的“过载”现象。

1.5 压测前的准备工作

在正式开始压测之前，有几件事我建议你先做好：

• 明确目标：这次压测要测什么？是测登录接口，还是下单流程？目标要具体
• 准备环境：最好用独立的压测环境，别在生产环境上乱搞。我曾经见过有人在生产环境压测，结果把线上服务压挂了
• 监控到位：CPU、内存、网络、磁盘IO、数据库连接数，这些指标都要能实时看到
• 数据准备：压测用的数据要模拟真实场景。比如用户ID、商品ID，不能都用同一个

好了，这一章的内容就到这里。吞吐压测的核心概念和指标，咱们已经讲清楚了。下一章我会带你搭建压测环境，手把手教你写第一个压测脚本。