2、核心指标解析:QPS、TPS、并发数、响应时间、吞吐量之间的关系

做性能测试这些年,我见过太多人一上来就盯着某个指标猛看。

比如QPS上不去就加机器,响应时间慢了就怪代码。

其实这些指标是串在一起的,就像一根链条上的几个环。

你单独看哪一个,都看不出全貌。

2.1 先搞清楚每个指标到底在说啥

咱们先把这几个概念掰扯清楚。别嫌啰嗦,我见过不少工作了三四年的同学,聊起来还是一锅粥。

QPS(Queries Per Second)

每秒查询数。说白了就是系统一秒钟能处理多少个请求。

注意,这里的"查询"不一定是数据库查询,它泛指客户端发起的请求。

我习惯把QPS理解为"系统的门面指标"——用户感知到的就是它。

TPS(Transactions Per Second)

每秒事务数。这个比QPS更重一些。

一个事务可能包含多个查询。比如你下单买东西,从点击"提交订单"到收到"下单成功"的反馈,这整个流程算一个事务。

嗯,这里要注意:TPS才是衡量系统真实处理能力的指标。

核心区别:

QPS = 单次请求的吞吐能力

TPS = 完整业务流程的吞吐能力

一个TPS可能包含3-5个QPS,具体看你的业务逻辑有多复杂。

并发数

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

很多人把并发数和在线用户数搞混。在线用户数可能有一万,但真正同时在发请求的,可能只有几百。

我曾经帮一个电商平台做压测,对方说"我们并发一万",结果一查,实际同时请求的只有八百多。这就是概念没搞清楚。

响应时间

从发出请求到收到完整响应的时间。

我一般关注三个值:平均响应时间、95分位响应时间、99分位响应时间。

平均响应时间容易被极端值拉偏,95分位和99分位更能反映真实体验。

吞吐量

单位时间内系统能处理的总工作量。

它是个综合指标,通常用QPS或TPS来表示。但严格来说,吞吐量可以是任何单位——比如每秒处理多少笔订单、多少条日志。

2.2 它们之间到底啥关系?

我画了一张图,你看一眼就明白了。

核心指标关系图 并发数 同时处理的请求数 响应时间 每个请求耗时 QPS 每秒请求数 TPS 每秒事务数 吞吐量 影响 决定 决定 组成 组成 核心公式:QPS = 并发数 / 平均响应时间

这张图你看懂了吗?

核心逻辑其实就一句话:并发数和响应时间共同决定了QPS和TPS,而QPS和TPS又组成了吞吐量。

2.3 那个经典公式,你得刻在脑子里

做性能分析,有一个公式你无论如何都得记住:

QPS = 并发数 / 平均响应时间(秒)

举个例子你就明白了。

假设系统同时处理100个请求(并发数=100),每个请求平均耗时0.2秒(响应时间=200ms)。

那么QPS = 100 / 0.2 = 500。

也就是说,一秒钟能处理500个请求。

我的经验:

这个公式反过来用更有价值。如果你目标QPS是1000,平均响应时间是0.1秒,那你就需要1000 × 0.1 = 100的并发数。

这能帮你估算需要多少线程池、多少连接池。

2.4 实际场景中的指标联动

光讲理论没意思,我分享一个真实案例。

去年帮一家金融公司做压测,他们的核心交易系统。

一开始QPS只有200,响应时间平均300ms。并发数大概60左右。

我们优化了数据库索引和缓存策略,响应时间降到了100ms。

你猜怎么着?并发数没变,QPS直接飙到了600。

这就是响应时间对吞吐量的直接影响。

但事情没那么简单。

当我们把并发数从60提升到200时,QPS确实涨了,但响应时间也开始恶化——从100ms涨到了400ms。

为什么?因为系统资源开始争抢了。CPU、内存、数据库连接,都成了瓶颈。

注意:

并发数不是越大越好。每个系统都有一个"最佳并发数"。

超过这个值,响应时间会急剧上升,QPS反而可能下降。

这就是所谓的"拐点"。找到这个拐点,是性能测试的核心目标之一。

2.5 几个常见的误解,我帮你排排雷

这些年我踩过不少坑,也看别人踩过。说几个最常见的:

  • 误解一:QPS越高越好

    不一定。如果QPS是靠牺牲响应时间换来的,用户体验会很差。我见过一个系统QPS很高,但每个请求要等3秒。用户早跑了。

  • 误解二:并发数等于在线用户数

    这个前面说过了。在线用户数通常远大于并发数。一般比例在10:1到50:1之间,看业务类型。

  • 误解三:TPS和QPS可以混用

    千万别。一个TPS可能对应多个QPS。你用QPS去衡量事务处理能力,会严重高估系统性能。

  • 误解四:吞吐量只看QPS就够了

    不够。吞吐量应该结合业务来看。比如支付系统,我更关心每秒能处理多少笔交易(TPS),而不是每秒收到多少请求(QPS)。

2.6 怎么用这些指标做性能分析?

我个人的分析套路是这样的:

  1. 先定目标:业务要求的QPS/TPS是多少?响应时间上限是多少?
  2. 找基准:在低并发下测出基准响应时间。
  3. 逐步加压:慢慢增加并发数,观察QPS和响应时间的变化。
  4. 找拐点:当响应时间开始非线性增长时,那就是系统的极限了。
  5. 定位瓶颈:是CPU满了?数据库慢了?还是网络带宽不够了?

一句话总结:

并发数是"油门",响应时间是"路况",QPS/TPS是"车速"。

油门踩到底不一定最快,路况不好时反而会翻车。

性能调优,就是在找那个"油门和路况的最佳匹配点"。

好了,这一章的核心内容就这些。

记住那个公式,理解指标之间的联动关系,你就能看懂大部分性能问题了。

可可精品资料库