一、压测基础认知：吞吐量、TPS/QPS概念辨析与压测价值

做性能测试这么多年，我经常被问到同一个问题：“压测到底在测什么？”

说白了，压测就是给系统“上强度”。就像测试一辆车的极限速度，你得把油门踩到底，看看它什么时候会出问题。我刚开始做压测时，也以为只是简单发请求看响应时间，后来踩了不少坑才明白——真正核心的，是理解那几个关键指标。

吞吐量，英文叫Throughput。我习惯把它理解为“系统在单位时间内能干多少活”。

举个例子：一个快递站，一天能处理1000个包裹。那它的吞吐量就是1000件/天。换成系统，就是每秒能处理多少个请求、每分钟能处理多少笔交易。

嗯，这里要注意：吞吐量不是越快越好，而是“稳定地多”。我在项目中遇到过，某系统瞬时吞吐量很高，但持续几分钟就崩了——这种“虚高”没有意义。

吞吐量的核心公式：

吞吐量 = 完成处理的请求数 / 总耗时

单位通常用：TPS（每秒事务数）、QPS（每秒查询数）、RPS（每秒请求数）

这两个概念，我见过太多人搞混了。你想想看，面试时被问到“TPS和QPS有什么区别”，能答清楚的人真不多。

指标	全称	含义	典型场景
TPS	Transactions Per Second	每秒完成的事务数	下单、支付、转账
QPS	Queries Per Second	每秒完成的查询数	搜索、列表页、详情页

TPS 强调的是“事务”。一个事务可能包含多个操作。比如你在电商下单：先查库存、再扣库存、生成订单、扣减余额——这一整套才算一个事务。

QPS 强调的是“查询”。说白了就是读操作。比如你刷朋友圈，每刷一次就是一个查询。

我的个人经验：

做压测时，我习惯先区分业务类型。如果是写多读少的系统（比如交易系统），重点看TPS；如果是读多写少的系统（比如资讯网站），重点看QPS。千万别混着用，否则指标会失真。

为什么会这样？因为TPS和QPS对系统资源的消耗完全不同。TPS通常涉及数据库写入、锁竞争、事务日志，压力更大。QPS主要是缓存和索引的较量。我曾经遇到一个项目，团队用QPS去评估支付接口的性能，结果上线后直接被打趴——这就是概念不清的代价。

做压测，不是为了“测着玩”，也不是为了给领导看一张漂亮的报告图。我个人认为，压测的核心目的就三个：

我记得有一次，给一个金融系统做压测。刚开始测，TPS只有200，但CPU已经飙到95%。一看监控，发现是数据库连接池配得太小，请求全在排队。调整后，TPS直接冲到2000。这就是压测的价值——用数据说话，而不是靠猜。

避坑指南：

我曾经犯过一个错误：压测时只关注TPS，忽略了错误率。结果TPS很高，但大部分请求都返回了500错误。这种“虚假繁荣”比低TPS更可怕。记住：压测的黄金法则是“高吞吐 + 低错误 + 低延迟”，三者缺一不可。

下面这张图，是我自己总结的压测基础认知结构。你可以把它当作一张“地图”，后续学习时随时回来对照。

这张图把本章的核心知识点串起来了。你仔细看：吞吐量是最终结果，TPS和QPS是衡量它的具体指标，而压测就是获取这些指标的手段。三者环环相扣，缺一不可。

最后，分享一个我压测多年总结的“黄金法则”。你可以在实际工作中反复验证：

压测结果评估三要素：
1. 吞吐量（TPS/QPS）：越高越好，但必须稳定
2. 错误率：必须为0或趋近于0
3. 响应时间：P99 < 500ms（视业务而定，但要有底线）

记住：任何一个指标单独好看都没用。我见过TPS冲到5000但错误率30%的系统，也见过响应时间10ms但TPS只有50的系统。真正的好系统，是三个指标同时达标。

本章小结：

吞吐量是系统的“体力”，TPS/QPS是“速度计”，压测是“体检”。没有体检，你永远不知道系统什么时候会倒下。下一章，我们会深入聊压测工具的选择和实战技巧——嗯，到时候我会分享一些我踩过的坑，保证让你少走弯路。