关于压力测试中 TPS 和并发数的疑惑

昨天有雨 9
2022-07-18 11:48:06 未知地区 1F
回复

启 200 个线程不等于有 200 个并发吧简单来说，
并发数：可以理解多少个并发用户，比如 200 并发数可以理解为有 200 个严格意义上的并发用户；
TPS： 每秒成功处理的事务数，或者每秒处理的接口请求；

为什么你的案例中，200 个并发，TPS 只有 78？
表面原因

从表面来看，就是因为你的登录接口响应时间达到了 1961ms。
举个更简单的例子：用 1 个并发用户，请求登录接口，如果接口响应时间为 2 秒，那么 TPS 就为 0.5；
如上所示，200 并发 TPS 只有 78，是因为你们服务性能不足导致；

当然也有其他原因会导致实际并发小于设置并发的情况：
比如压力机性能限制，无法支持 200 个并发线程，就会导致，你设置了 200 个并发用户，实际资源只启动了 100 个并发线程运行。

所以，TPS 与并发用户不一定总是线性关系。二、指标

1、QPS（Queries Per Second）

概念：服务器每秒处理查询次数，是一台服务器每秒能够处理的查询次数。用户发起查询请求到服务器做出响应这算一次，一秒内用户完成了 50 次查询请求，那此时服务器 QPS 就是 50。

2、TPS（Transactions Per Second）

概念：服务器每秒处理的事务数，一个事物是用户发起查询请求到服务器做出响应这算一次。纳尼？这难道不是 QPS 的概念吗？划重点，这里就要说清楚一个概念了，在针对单接口，TPS 可以认为是等价于 QPS 的，如访问 ‘order.html’ 这个页面而言,是一个 TPS。而访问 ‘order.html’ 页面可能请求了 3 此服务器（如调用了 css、js、order 接口），这实际就算产生了三个 QPS

所以，总结下就是，在针对单接口的时候 TPS = QPS ,否则 QPS 就要看实际的请求次数了。

2、RT（Res（onse Time）

概念：响应实际，就是从客户端请求发起到服务器响应结果的时间。RT 这个参数是系统最重要的指标之一，它的大小直接反应了当前系统的响应状态。基本和咱们用户体验息息相关，现在好一点监控系统一般都有三个 RT，即平均、最大、最小。

一般系统 RT 100ms 以内是比较正常的，300ms 勉强可以接受，1s 的话再加上一些其他的外因，给用户的体验就是实实在在的不爽了。

3、并发数

概念：系统能同时处理的请求的数量，很多人经常会把并发数和 TPS 理解混淆。举例，请求一个 index.html 页面，客户端发起了三个请求（css、js、index 接口）,那么此时 TPS =1 、QPS =3 、并发数 3。

SO，计算公式 ：QPS=并发数/RT || 并发数=QPS*RT

4、吞吐量（Throughput）

概念：每秒承受的用户访问量，吞吐量（系统能承受多少压力）和当前请求对 CPU 消耗、内存、IO 使用等等紧密相关。单个请求消耗越高，系统吞吐量越低，反之越高。

一个系统的吞吐量和其 TPS 、QPS、并发数息息相关，每个系统针对这些值都有一个相对极限值，只要其中某一个达到最大，系统的吞吐量也就到达极限了。如此时压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，各种资源切换等等的消耗导致系统性能下降。

关系：

所以，理解上面几个关系后，就可以推算出：

QPS（TPS）= 并发数/平均响应时间

5、PV（Page View）

概念：即每个页面的浏览次数，用户每次刷新就算一次。

6、UV（Unique Visitor）

概念：独立访客数，每天访问的用户数，此数据需要根据用户唯一标识进行去重。

7、Load（系统负载）

概念：此数据指的是 Linux 系统的负载情况，也就是咱们平时所用 Top 命令时，最上面显示的数据信息 ( load average: 0.1, 0.2, 0.5)。此时会显示 1 分钟、5 分钟、15 分钟的系统平均 Load，很显然 load average 的值越低，你的系统负荷越小。

简单的说下这个值应该怎么看，如果你是单核 cpu,那此值为 1 的时候就是系统已经满负荷状态了，需要你马上去解决。但实际经验告诉我们，当系统负荷持续大于 0.7 的时候（也就是 70%），就需要你马上来解决问题了，防止进一步恶化。

为什么需要三个值 load average: 0.1, 0.2, 0.5，其实就是给你个参考。比如只有 1 分钟的是 1，其他俩都是 0.1，这表明只是临时突发的现象，问题不大。如果 15 分钟内，系统负荷都是 1 或大于 1，那表明问题持续存在啊。所以你应该主要观察 15 分钟的系统负荷。1.我在 jmeter 中设置 200 个线程，那理论的并发数应该就是 200。
2.我计算出来的实际并发数是 153。

我可不可以这样理解，这个差值是由于：
服务器处理性能不足，导致我虽然让 200 个用户同时去登录，但是有部分用户的请求卡在了通道上，只有 153 个用户在登录，其余的处于等待状态。
等前面 153 个用户登录完了，剩下的 47 个用户才能去登录 (服务器才能处理这些请求)。实际并发数是怎么计算出来的？实际并发数 = 系统在某一时刻同时处理的事务数 = 某一时刻同时登录的用户数 = TPS * 平均响应时间 AVGRS = 78.4 * 1.961 = 153你的推测有一定可能性，但是原因可能如下：
（1）被测服务最大连接数限制导致（这个可以查看一下当前连接数是否达到了最大连接数）；
（2）被测服务资源有限，无更多资源分配给新建连接数导致；
（3）压力机资源限制，导致无更多资源分配给并发线程；不是这么算的，这块的概念你没搞清楚。先查一下，什么叫实际并发数？

同一时刻同时登录的用户数 != TPS * 响应时间，这个公式完全不成立。
严格意义上的并发用户数：指与系统建立连接，并对系统发起请求，对系统造成压力的用户；
注意：并发用户数不能完全代表对系统的压力，比如 100 并发用户与系统建立了连接，每秒发一次请求，每 10 秒发一次请求，这两种行为对系统的压力是完全不一样的。

可以通过查询 被测服务器有多少来源于压力机的 IP 与服务器建立了连接，来计算真实并发。社区的人真的要好好看看这些基础。亲，取 95% 或者 90% 的响应时间哦在计算什么东西的时候，取 95%line？靠谱一点的结果，都是取 95% 响应时间你派遣了 200 个士兵（线程数）前去攻城
但是护城河上的桥（性能瓶颈）只允许 150 个士兵同时通行，剩下的士兵只能排队（所以 TPS 上不去了）你 200 的并发设置集合点了吗，如果设置了集合点，又长时间跑的话，中间那个线程启动时间肯定是加到你的总时长里去了，况且计算 TPS 的时候为什么要除以总时长呢所以结论是什么？
并发数=TPS * RT（平均响应时间）在未达到瓶颈时是成立的，达到瓶颈后就开始不成立了？线程数当然不能等同于并发数了，难不成你想一条线程只输出一个 TPS？？ 那假如我要 30000 并发，你要开 30000 线程？ 那你 CPU 几 C 的？这会有多频繁的上下文切换？有多少资源耗费在其中？
实际并发数=发压端线程数每个线程输出的 TPS
TPS=（1000ms/平均响应事件）发压端线程数
你 TPS 不变的情况下，加线程数只能拉低响应时间，没有其他意义