📚 课程目录第4章并发概念与性能指标

第4章并发概念与性能指标：QPS、TPS、并发用户数定义及关系

做SM4密码卡容量审计，绕不开几个基础概念。老实说，我刚开始接触性能测试时，也被这些名词搞得头大——QPS、TPS、并发用户数，看着好像差不多，但实际意义完全不同。

这一章，咱们就把这几个东西彻底讲透。你理解透了，后面的容量建模和压测脚本设计才能站得住脚。

很多人以为并发就是“同时发生的请求数”。这个说法没错，但不够精确。我给个更落地的定义：并发是指系统在单位时间内能够同时处理的业务请求数量。

举个例子，我早年测试一个SM4加密网关时，用户量一上来，系统就开始丢包。当时我以为是硬件不够，结果一查日志——并发控制参数的配置有误。说白了，并发不是用户数量，而是系统同时承载的处理能力。

在SM4密码运算场景里，并发通常指：

每个场景的并发特征不同，不能一概而论。

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

注意，QPS一般用于查询类操作，比如读数据、查状态。在SM4场景里，如果你只是查询密钥是否存在、查询设备状态，那用QPS更合适。

// 一个简单的QPS计算示例
// 假设有10个并发用户，每个用户发送了100次查询
// 总请求数 = 10 * 100 = 1000
// 耗时 = 50秒
// QPS = 1000 / 50 = 20

为什么会用QPS？我个人习惯在系统压力不是特别高、操作类型是查询时，优先看QPS。它更直观，也更好计算。

我的经验：做SM4密码卡容量审计时，如果发现QPS突然下降，先看是不是并发数配置超过了硬件上限。我曾经遇到过一块SM4密码卡，标称QPS是5000，实际压测跑到3000就开始抖动。后来发现是驱动层的并发队列太小，根本吃不到那么多请求。

TPS全称是Transactions Per Second，每秒事务数。它比QPS更重，因为它衡量的是完整的一笔业务能处理多少。

什么叫“一笔业务”？在SM4场景里，一笔业务通常包括：建立连接、发送密钥、加密数据、接收结果、关闭连接。这个流程里可能包含多次网络交互，负载要比单纯的查询大得多。

你想想看，如果系统标称TPS是1000，那意味着每秒钟能完成1000笔完整业务。这个数字通常比QPS小很多，因为一笔事务包含的步骤是多次QPS的累加。

我建议你在做SM4容量审计时，先用TPS做基准评估，然后再看QPS。为什么？因为TPS更贴近真实业务负载，QPS更偏于理想状态。

并发用户数是最容易被误解的概念。很多人以为并发用户数就是系统同时在线的人数。大错特错。

并发用户数指的是同一时刻对系统发起请求的用户数量。和“在线用户数”是两回事。

举个例子：

在我之前做的一个SM4密钥管理系统项目中，客户说他们支持5000个并发用户，结果我一测，实际压到2000并发就开始报错。后来查原因：他们把“在线用户数”当成了“并发用户数”来设计。嗯，这个坑我踩过，希望你别再踩。

注意：并发用户数不是越大越好。每个并发请求会占用系统资源（CPU、内存、网络连接、加密卡硬件线程等）。如果并发用户数设得过高，系统会因为资源耗尽而崩溃——这叫“雪崩效应”，后续我们会专门讲。

QPS、TPS、并发用户数之间不是割裂的，它们通过一个公式关联起来：

并发用户数 = (TPS × 平均响应时间) × 一个系数

或者更直观地：

QPS ≈ TPS × (每个事务包含的请求数)

为什么是“≈”？因为实际系统中，每个事务的请求数可能不是完全固定的。而且响应时间本身会随着并发数的变化而变化——这就引出了“漏斗模型”。

我画过一张图，可以帮你理解它们之间的关系：

这个图你能看懂吧？并发用户数就是水流的上游。它决定了请求到达系统的速度。QPS和TPS是系统的处理能力，两者通过业务逻辑的组装程度来转换。响应时间则是下游反馈，响应时间越长，系统能支撑的并发用户数就越少——这是一个闭环。

我当初做SM4容量审计时，就靠这个模型来预估系统瓶颈。举个例子：

聊了这么多，我总结几个常见误区，你对照一下自己有没有中招：

    一句话总结：做SM4容量审计时，并发用户数、QPS、TPS、平均响应时间这四个指标要一起看，缺一不可。只看一个，就像只盯着仪表板上的一个表盘开车——迟早出问题。

好了，这一章就到这里。你理解透这些概念，后面讲容量建模和压测脚本时，就会发现其实都是围绕这几个指标在做文章。

第4章 并发概念与性能指标：QPS、TPS、并发用户数定义及关系